Re-display password in registration form good or bad?

When a user tries to register and the data he submits are not right such as bad email, or weak password, we would display the registration page again to him with the data he just submitted along with the error messages.

My question is should we display the password he just submitted in HTML as this?

<input type="password" value="s0me7Xpwd">

Or just leave it blank and annoys him to enter another one?

It's definitely better in user experience to insert the password again (especially when the password is all right) but would it be good with regards to security?

 

As long as you don't store it anywhere, ie only pass it back to the form via POST, it shouldn't matter, security wise. You have to pass it via POST anyway, to process it for input to or check against existing values in the database. Returning it to the form on failure doesn't really expose anything more (except it's visible in the source if a user looks there).

 

Never EVER send something like a password back in a form; it's broadcast completely in the clear and just increases the likelyhood of MITM interception. (admittedly with most forms

Generally speaking password handling should be mono-directional. From the user to the database and NEVER the other direction... that's why you use an "irreversible" (yeah, right) hash to store them and if someone forgets their PW you issue a new one. That's why well written login queries will hash/crypt the pass before sending it to SQL and let SQL do the comparison, instead of retrieving the pass and comparing in whatever server-side language you are accessing SQL from.

The more you pass it around, the more chances there are for it to be intercepted; so the best policy is ALWAYS to limit how much you pass it around. Keeping the value and sending it client side again? Just ASKING for it to fail. There's always at least ONE interception opportunity, why create two or more extra ones?

Rather than take that approach, since it sounds like you are making a new user do you have TWO password fields that are compared? If they pass the compare store it using the same hash method you would in your database in the SESSION, and send a message "Password ok" instead of in the form; use a hidden input with something like "passwordReady" as it's name saying to pull that value from the session when everything else checks out.

Again, good rule of thumb, once a password has been verified and/or hashed, destroy it... Part of why the nonsense I've been seeing lately of developers putting the SQL un/pw/hostname into DEFINE is mouth-breathingly idiotic and just BEGGING to get hacked.

@PoPSiCLe -- visible in the source means visible in the CACHE, and that's a pretty big concern unless the person registering is constantly flushing. You get some joker on a public terminal and all they need to do is browse the cache to find the PW... That couldn't POSSIBLY come back to bite one in the arse, could it?

At that point one might as well send the password as GET.

 

Well, I was taking a look at how Firefox handles a login on a https-website (I have control over the site) - I can't find, anywhere, the actual password being entered and submitted, EXCEPT if I use a packet-sniffer (I guess I can intercept the password here, haven't succeded as of yet, but I didn't let it run very long, and I haven't bothered manually going trough it) - however, running a packet-sniffer means that 1. I have to be on the same network, and 2. I need to have access to the traffic to and from the network-node in question (not too difficult to pull off, but still). Reading the cache in Firefox reveals nothing readable, although I'm sure it can be deconstructed to show something - however, personally, I regard these as a minor threat. Also, depending on how the form is being processed, it might not even be needed to send the password more than once - one could simply do a ajax-request for other variables being checked, and if all seems fine, post it normally - then on return, if it was the wrong password, for instance, just return to the login-page with a "wrong password" message and an empty field.

 

@PoPSiCLe - yeah, I forgot to mention "use HTTPS" if one really cares about securing it.

Still, returning the empty field or storing it server-side in something like $_SESSION isn't a giant effort or great big difficult thing. Even if it's a minor threat, a healthy dose of paranoia NEVER hurt in form handling or processing user input.

Just see all the cases of people getting hacked or having things leaked due to skipping things like this.

 

I sorta agree with you on that - I thought "use HTTPS" was sort of a given - don't have sensitive info, like a password, on a HTTP-page. But of course, that might have been a bit of wishful thinking. It's almost like we shouldn't wait to get the new standards in place... I still don't understand why HTTPS haven't been set as default ages ago.
As for having an empty input field for password, it's not a very big thing, but if the error preventing the form from being submitted isn't the password, but something else the user has forgotten to fill out, it can be an annoyance - I dunno - in a login-form, it might not matter that much (there are usually only two fields anyway), but for more complex forms, where a password is needed (registration form, for instance), it is an annoyance to the user - which, unfortunately, don't have a clue about security, of course, and only want things to be as simple as possible.

 

Sad but true -- though:

Performance, it's slow. Sad, but a LOT of people will sacrifice security for speed or convenience, again not to flagellate the deceased equine, but see things like putting security info into DEFINE, relying on off the shelf frameworks/CMS without knowing enough about the underlying languages to know if it's ACTUALLY secure or good practices or not, and so forth.

It's why usually if someone is creating their password, I try to keep the number of fields limited and/or have the password creation the only thing on the form. It may be a slight annoyance to have the extra page-load, but it avoids a LOT of the issues we're talking about here. If there's extra info for them to fill out, put it on another form.

Though again, I know a lot of people get the "pageloads are evil" paranoia going full blast on that concept, probably because they'll waste hundreds of K of markup, hundreds of k of CSS and hundreds of K of JS on doing 10k or less markup 32k or less CSS (that should be cached) and zero JavaScript's job.

 

So how to store sensitive information / credentials in my PHP code?

 

Yes, it would be good in security aspect. Have them edit the password once again.

 

Local scope to a function or method, used ONCE to connect and immediately destroyed, just as the database handler variable/object should only be passed to functions/methods/objects that NEED it and never passed to any code that doesn't need it. Passwords coming from user side likewise should be destroyed as soon as verified, and things like user permissions should be accessed via a GETTER and stored in local scope to an object that pulls it from the database, reducing the odds of privilege elevation.

PHP's scope on includes (which is just stupid) and blindly running code makes it harder to actually do -- and certainly it's harder to prevent exposure of SQL passwords with readfile and fopen being able to read/write .php files (something they NEVER should have been allowed to do in the first place), but that's no reason to hang the keys to the entire kingdom next to the front gate.

There are a LOT of "good practices" for interpreted/scripting languages it seems PHP devs are ridiculously unaware of -- concepts like not passing scope to includes, not putting things like passwords and database connections into the global scope, not allowing libraries to output anything if called directly... This is stuff we knew twenty years ago in languages like COBOL or Clipper... I look at systems -- like turdpress, like codeignitor, like laravel -- and just shake my head going "Whiskey tango foxtrot!?!" as the most basic of security policies are nowhere to be found.

Even PHP itself is guilty of this; I already mentioned readfile/fopen/file_get_contents being allowed to open source files (BAD idea) -- there's also the dipshit allowing of include/require being able to open files that don't end in .php; SO many ridiculously simple methods of pwning PHP based software would never even have existed if such a simple check were in place!

A similar issue is include/require passing the scope of wherever it's called from; this is one of the dumbest things you can do with library files since GOOD library files should be filled with nothing but objects/methods/classes and NOT anything that runs / outputs JUST because you included it. JUST so I can break scope I actually use this:

function safeInclude($file) { include($file); }

Code (markup):

To break scope! It's insanely dumbass that, well... take this example:

testInclude.php

<?php echo $test, '<br>'; ?>

Code (markup):

test.php

<?php
function safeInclude($file) {
	include($file);
}

function test() {
	$test = 'This is a test';
	include('testInclude.php');
	safeInclude(testInclude.php');
}
?>

Code (markup):

Will actually output 'this is a test<br>' on the include, but behaves as if $test is not defined (what IMHO should be the correct behavior) when safeInclude is used. Imagine if $test was your PDO object!

It's part of the sleazy "let's make it a scripting language instead of a real programming language" practices that makes PHP "insecure by design" making it an uphill fight to secure much of anything.

Though they FINALLY fixed and are forcing the move away from mysql_ functions by shoving it down people's throats; which is basically what it's going to take at this point given what utter and absolute crap those were on most every front. Most people think that blindly pasting variables / data into queries was the 'real' security hole, but just as bad is that the moment you did a mysql_connect the connection was global in scope available to everything. If you know the first damned thing about interpreted scripting languages that can blindly include other source files that is so incredibly herpafreakingderp that derpity derp derps go damn, could you derp that a little less? It's special, in the same way some olympics are special.

It's still some serious herpaderp and some minor changes would go miles towards making it more secure; unfortunately many of the insecure practices are so deeply ingrained in the current developer mindset it's an uphill battle to get people to stop sleazing out code any old way. Same problem that faces most web technologies like HTML and CSS where generally speaking and as I keep saying, most people refuse to pull their heads out of 1997's arse. Just look at HTML 5 as a prime example of when the momentum for "sleaze it out" was so bad, the W3C shrugged it's shoulders and gave up on actually trying to make HTML better.

But really some very simple fixes could go miles towards 'fixing' what's wrong with PHP.

1) No more <?php ?> shorttag nonsense. Make EVERYTHING be code, you want output, use echo. PERIOD, full stop, end of story! (and axe every other method of output, yes C style formatting "sprint", I'm looking at you!). No more idiotic HEREDOC, NOWDOC, or blindly outputting anything that isn't in a properly ordered string and/or set of delimits. (with emphasis on comma delimited echo output instead of the grossly inefficient double quote processing and string additions people crap all over their code with)

2) Prevent any normal file operation from being allowed to read or write source files (use .php extension as the trigger). This includes swinging an axe at the idiotic "readfile".

3) Prevent any include/require from being able to run code from files with the wrong extension. (again, using .php as the trigger)

4) Eliminate the possibility of calling the command line directly for anything. (seriously) You want to call a external command make it so a whitelist of allowed executables must be maintained in the php.ini

5) get rid of EVAL entirely, it serves NO legitimate purpose.

6) make include/require break scope to global instead of local to the function being called.

7) Make it so files called with include or require throw an error if there is anything other than functions or classes present in them! This is another "shove our **** down developers throats to MAKE them behave" concepts.

Of course, none of this will ever happen as people are too used to the language being "insecure by design" and filled with rubbish concepts that have no damned place being used in the first place... though I'm not alone on a number of these concepts -- just look up "disable php functions" for security on Google and you'll come up with tons of people saying to neuter the file read functions from the php.ini.

The only reason I put up with and develop in PHP is that it's ubiquitous; JUST TRY finding a host that doesn't support it. It's EVERYWHERE, it's platform independent, you can rely on it being available. Likewise it is RIDICULOUSLY well documented; PHP.NET putting to shame pretty much every other langauge's documentation since Borland stopped distributing printed manuals for thier compilers. -- despite all the shortcomings (and boy it has some whoppers) it is still head and shoulders over the alternatives.

You want node.js or server side java, some hosts will tell you to go plow yourself. Everything "wrong" with PHP is a dozen times worse in PERL, Python blows the proverbial equine of short stature when it comes to dealing with large strings or large amounts of markup since it's strings aren't whitespace neutral, and most other languages require native compiliation; you think hosts are hostile to letting you run stuff other than Perl or PHP, try asking permission to run a native executable.

If there were a practical alternative with actual traction, I'd be using it -- sadly most of what's out there is worse. See languages like Ruby and Python that after some 30+ years of programming makes me wonder just what the **** is wrong with people?!?

...though admittedly, I've been saying that since C caught on in mainstream programming; I can't imagine why! -- I'm so old-school I still call K&R "New kid BS" and would still sooner hand assemble 8k of Z80 machine language than deal with 100k of C code.

Of course one of my other side projects is an attempt to make my own interpreted web language (core interpreter/parser is called "Gruesome", web language based on that core is called "Gossamer". Also working on an frameless MDI IDE built for it using Scintilla called "foghorn"), but like a great number of my projects it's languishing unfinished as my health, time and stamina for such things is greatly limited. (See spending two or three days a week in the ICU being two or three time a month event now.)

But in any case, the real answer to your question is keep things like server-stored SQL passwords local in scope, when you get a password via $_POST hash it ASAP and destroy it the MOMENT you are done with it so any code past that point has zero access to it. Same reasons you don't put the user "level" / permissions into global scope as writable. (something singletons excel at implementing thanks to "private" with a getter).

You fail to do these things, well...
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=joomla

90% or more of which wouldn't even exist if PHP wasn't "insecure by design" and/or implemented the fixes I outlined above. Bad practices in a insecure language WILL bite you sooner or later. Unisolated scope of secure information and failure to kill security info when done with it being just as broken as blindly trusting user input or passing things like passwords via $_GET -- or using things like $_REQUEST (something else I'd kill off)

 

While I agree with a lot of these sentiments, I also think that some of the functions you berate are some of the reasons PHP has caught on as it has. The scope being more global than local, for one, and the fact you can include files which relies on variables present in the file the include happens in - most of those are pretty much used everywhere (while it might not be a super smart decision, it's still common, and if you remove it, you'll pretty much break everything).
As for the ability for PHP to write and read PHP-files, I like that function - as long as it's used in a smart way - for instance, my config.php is created when you run setup - it takes a config.sample.php (which have some ready-set variables already set, and adds the variables needed for installing the project, like database name / password etc.) - yes, of course I could make the user edit the file manually and upload it, but that would be immensly less user friendly, in my opinion. Of course I could have gone with the ini-approach, but I seriously don't like the functionality it represents. This wouldn't be possible if all the ways of reading, parsing and writing php-files were taken away.
DEFINE I only use for text-replacement (language files) - again, I don't really like the built-in functionality for language-parsing in PHP.

 

Sad but true -- unfortunately that's NOT a good thing as it's let a LOT of people who have ZERO business making or even simply running websites do so, and piss their own beds in the process.

Breaking "everything" isn't bad when it's already broken rubbish people shouldn't be doing in the first damned place. The notion of an 'include' where the file is just blindly pasted in as if it was actually in that location in the source is just begging for a way to be pwned; more so when there's no filename verification. See how often people get burned by user uploads getting executed either directly or by include, and how quickly that would fall flat on it's face with what I'm saying.

Sometimes I wish the people making the technologies others use were a bit less gun-shy about breaking things when what's being broken is bad practice, insecure, or just plain wasteful. See HTML which is WAY too forgiving... Web would be a VERY different place if instead of plodding on pointlessly and silently HTML parsers would STOP and throw an error when people screw it up.

That's part of why I'm REALLY glad that in PHP 5.5 they finally manned up and made the mysql_ functions throw errors; though really they should have gotten rid of their entire implementation instead of "let it work, but throw an error". Sometimes you've got to run before you can walk.

... and that's another thing I would never, EVER do in my PHP... or if I DID allow it I'd immediately go in via FTP or BASH and do a "chmod 444 config.php" -- at which point you might as well just edit the blasted file directly.

... and that's another excuse I'm REALLY sick of hearing. If someone can't be expected to edit one simple file and upload it, they likely have ZERO blasted business installing software in the first damned place. To the point of that level of "user friendly" being some serious herpafreakingderp. It's the online equivalent of people at home putting their password on a post-it note and sticking it to the monitor.

Laughably I just dealt with my neighbor who couldn't figure out how after adding parental lockoust to their system the kid was still getting through to "objectionable" sites. Duh, the password to override it was on a sticky on their bedroom mirror!

But I guess Ron White is right, you can't fix stupid.

You have to draw a line on being user-friendly at some point; particularly when said user friendliness is over something that should be set once in a blue moon (install, move to another server, when compromised), involves a process that someone knowledgeable should be handling in the first place, and that is for all intents and purposes the keys to the kingdom. Sacrificing security on the alter of 'user friendliness' is WAY too common a practice and there's no legitimate excuse for it in the majority of cases. We MAY just have to go "look, you're too stupid to do this, so either hire someone qualified or golf tango foxtrot oscar"

Sorry if that sounds elitist, but it would probably cut down on the number of dipshits who have NO business owning or managing websites being duped, abused and misled by the sleazeball scam artists that have taken over the industry. Naturally said "sleazeball scam artists having taken over the industry" means we sure as shine-ola won't ever see that happen; quite the opposite. Look no further than what's going on with the Google Webmaster stuff for proof of that; where Pagespeed Insights has become more of a shill for selling CDN's than a practical tool, and their PageSpeed Service makes good sites slower AND pisses away accessibility thanks to gibberish use of markup and scripttardery all in the blind hope of making really crappy sites load in 30 seconds instead of two minutes.

The laugh being a lot of what Google Webmaster pages are now saying contradicts the stuff coming out of the anti-spam team; talk about left hand not knowing what the right hand is doing!

Again, you say that like it's a bad thing. I'm talking about stamping out bad practices -- and you don't need to look much further than that. Remember, popular doesn't necessarily mean good!

Just look at the Food Babe, Dr. Oz, Jim Jones, Hitler, both of the major US political parties, anti-vaxxers, anti-gmo foodies, the endless horde of auto-tuned tone-deaf bimbo's passing as female pop stars right now like Beyonce, Taylor Swift, or Justin Bieber! Testimonial, plain folks, transfer, name calling, card stacking, and bandwagon are powerful stuff and can make Joe Sixpack and Susie Sunshine do some batshit insane nonsensical bull.

Nothing wrong with DEFINE if you use it for things that aren't a big deal to expose; the same actually goes for global scope. Things I put into define include the http root of the site (usually but not always "/"), http root of the current theme (http_root . '/template/themeName'), type of SQL connection (mysql, postgre, mssql, etc)... they don't expose anything dangerous or that couldn't be figured out anyways; they ARE values that I don't want being changed once set (nope, never used version 1.x of SMF).

In fact, if I were using single entry-vector design I'd even consider putting user permissions there if not for my "don't load it 'till you need it" object methodology.

The problem is that many developers don't seem to grasp scope, flail around blindly, and end up putting things into a global scope where it can't be unset (DEFINE) that has no damned business there -- Again see turdpress' idiotic halfwit placement of the SQL username and password in it. No wonder every time there's a code or privilege elevation opened by a mod / extension / plugin / whateversATrendyNameThisWeek the entire system is open to being utterly and completely pwned!

DEFINE for multi-language texts is an interesting one. I generally have a singleton (texts) that I pass the desired text and it's parent module name, texts::get($text, $module) which first sees if that modules language is loaded in a private array to that object and returns it if present; if not found it then goes looking for it, loads it, or returns an error/missing text message.

Again, using a singleton so I can isolate scope to prevent texts from being dicked with by a code elevation because, no matter how good a programmer you are mitsakes od hapepn, and in interpreted languages mistakes are VERY costly. Same reason I usually have a 'user' singleton that does the same thing with user information only pulling what's needed when needed with the user info and permission 'private' and only retrievable via a getter... said getter also being a setter for information not already retrieved.

PRIVATE in PHP objects being one of the few saving graces in the language, though I often wish there was a "read only" type where anything can read the variable/property, but only the object itself can change it -- then we wouldn't need a "getter" method when trying to isolate scope but preserve values. That's one bit of functionality i'm kind-of surprised PHP doesn't provide; alongside things like actual destructor forms. Volguus Zildrohar, the Traveler has come! Choose and perish!

... but as a friend recently said PHP is a hodge-podge of different methodologies with no real solid plan to it, where objects were shoe-horned into the language haphazardly. (more haphazardly than C++ being the real shocker).

Laughably that makes how well it's documented PHP is even more impressive. It might not feel like it had a plan at the start, but at least they took the time to write down what was done.

 

Well... I don't see the problem with having PHP write stuff to the root folder (as it does with the config-file) - the permissions on the files are still 644, which I think is "good enough" - it allows owner (PHP) to read and write - and others to read. Of course one could change it to 444, but that will make changing stuff hard if that's part of the admin-interface, for instance (of course, again, one could argue that a user wanting to change something should download the file, change it, and reupload, but that's not always the way things need to work). For one, creating pages not completely DB-based, but with actual files, will be impossible if it's not possible to write to the folder.
Your argument about including user-uploaded files, however, goes towards "never trust anything a user provides" - and while the upload-functions might allow for adding parseable files (like a PHP-file), that wouldn't be very wise to allow - hence why we limit the types of files allowed etc.
I do get the idea of not allowing any write-operations, or just allowing it to a certain directory (for downloads, for instance), but again... not always possible.

 

Wow, I might as well grab a cup of coffee and get down reading...

 

Methinks we have a different definition of "way things need to work" -- but notice I specifically said that reading/writing to .php files should be blocked. That's the one I'm usually concerned with as creating code/includes on the fly is the road to failure (I learned that lesson the hard way two decades ago) -- self modifying code, particularly in web technologies is just begging to be pwned, as is the placement of things (like admin panel type stuff) in files that the INTERPRETED scripting language with BLIND INCLUDES is just begging to be hacked. It's like having a door lock so pathetic it can be popped open with an index card.

It is in fact the same type of idiocy as EVAL or blindly allowing shell execution. The language itself isn't secure enough to allow those to be done.

It also depends on the type of data being stored; but honestly if you aren't using an SQL engine you probably shouldn't have a web technology making changes to ANY files whatsoever apart from perhaps letting uploads be copied to a subdirectory. That might make it "harder" and mean yes, to make changes you have to download, edit and re-upload, but it also hardens the systems against things that such a ridiculously "insecure by design" language leaves the door open to... and if that makes it "too hard" for Joe sixpack and Susie Sunshine to use, MAYBE they shouldn't be managing a website in the first place!

Unless you only allow modifications by actually using something like FTP to upload/download changes. Is that harder? Yes, is it more secure? well, yes. Databases also exist for a reason and it's not just indexing and efficiency of access speed, but also as a security isolation; which is why the insecure storage of the login and way you can blindly just "readfile('config.php')" inside a code elevation is ridiculously mind-blowingly STUPID. (To the point of being akin to the problems Clipper had 25-30 years ago)

... and that limiting works how well exactly? Oh wait, not at all, since there's nothing stopping a code elevation from doing "include('uploads/userupload.txt');" and php like a **** moron will actually run that .txt as PHP regardless of the extension. That's just herpafreakingderp and has been exploited so many times the past decade and a half I'm shocked they haven't plugged that hole.

I mean really, all I'm really talking about is:

1) not letting PHP write or read .php files with normal file operations like file_get_contents, fopen or readfile

2) not letting include or require read files that don't have the .php extension

3) getting rid of the idiotic PHP "shorttag" nonsense that results in massive security holes just to let dipshits who really have no business programming sleaze it together pretending it's a markup language.

... and to go with that, NOT allowing major security related items (like SQL un/pw/hostname) be set or modified any way OTHER than actually editing the file and uploading it since putting that into a web interface is re-re nonsense done by people not qualified to open their yap on how to secure things.

Things like letting your CMS or other server side code write it's own security files treads fairly close to being "false simplicity" and most certainly is idiotic halfwit bull in terms of even bothering to have things like passwords and usernames in the first place.

Again, not to make the same comparison over and over, but letting php write to files that can be called by include is just a sick perverted way of making a less secure eval... and letting readfile, fopen and their kine be able to read source files is equally idiotic since it means they can blindly load in and vomit up as output the files containing security info.

Do you mean "not always possible", or do you mean "not always possible if you're going to allow dipshits who probably shouldn't have a website dick with things they probably shouldn't even be trying to do?"

Again, kind-of miss the days when there was a sign next to the door of the web saying "You must be this smart to get on this ride". We've simplified things down for the Dukes and Dimwits to the point that we have a massive internet wide problem of "security, what's that?"

To go with the "Accessibility, what's that?", "HTML, what's that?", "Separation of presentation from content, what's that?", "What do you mean this doesn't need JavaScript to do that?", "What do you mean frameworks actually aren't easier?" and all the other bull that's popular right now that leaves me with little left for the industry other than two fingers; one for the developer and one for the source they code in on.

But as we've well established a LOT of developers do things I would NEVER even CONSIDER attempting to do on websites in the first blasted place, from "obvious security holes are obvious" to "what the hell does this do other than make the site harder to use". Hence my frequent use of the phrase "Not viable for web deployment"

@PoPSiCLe many of the things you've used to defend letting files be blindly written and read falling neatly into the "has no business being done on a website" category; even if they do make life "easier" for dipshits who likely have no business managing a website in the first place, that one pro cannot outweigh the cons of basically playing Russian roulette when it comes to security.

 

Well - first of all, you're not letting anything from an upload-directory be included or required - if anything, they're shown using a href or src - as far as I know, that doesn't allow for any execution of code - or am I mistaken? (Of course, a javascript or HTML-file will run when clicked, hence why one doesn't allow for those to be uploaded).
As far as I can remember, one can limit PHP to just parse files named *.php - and not parse anything else? Seem to remember setting up something like that (albeit in a different setting) when there was a need to parse CSS via the PHP-parser (don't ask).
I do agree that the simplicity is somewhat debilitating for the web as a whole, but then the web would be an insanely boring place if it wasn't for a lot of the "crap" - granted, it might be more secure and less of a pain-in-the-ass to use too, but I dunno if I'd be willing to switch.

 

You do know what a code elevation is, right? The types of goofball mistakes that result in tricking the system into doing an include or require of an arbitrary file? Running small snippets of code directly in the scripting? The thing that plagues phpBB repeatedly (no, REPEATEDLY), is part of why turdpress is an insecure mess, etc, etc?

Classic example being the Avatar system in SMF 1.6/earlier where you could BS the user info form to manually set the theme directory, which could then be bullshit into including an avatar via include instead of the base template file. This is **** that shouldn't even be possible and while yes, the REAL problem was with that profile form, that any user uploaded file could be hacked into being included is precisely what I'm talking about blocking.

Turdpress with it's "outer wall only zero internal defense" mentality is RIDICULOUSLY vulnerable. Most people seem to have it in their heads that once you have a code elevation all bets are off; when if people just practiced scope, limited scope, and the underlying language didn't blindly allow including files it shouldn't be allowed to include or write to files it has no business writing... This becomes painfully apparent when you get into mods/plugins/extensions/whatever that are typically NOT written with sufficient knowledge of the underlying system much less security -- see why MOST of today's turdpress vulnerabilities are created by the plugins -- but MOST of those vulnerabilities wouldn't even exist if internally Wordpress' idea of security offered more safety and protection than Grand Cayman in hurricane season.

Mind you, since version 3 dropped a few years ago Wordpress has made leaps and bounds on securing that outer perimeter, but internally their security policies reeks of "security, what's that?!?" -- It would be like having an outer perimeter of electrified chain link fence with razor-wire at the top around Fort Knox, but then not having anyone inside that fence or even bothering to lock/secure any of the security checkpoints or doors inside it.

... and even that outer fence is ridiculously ridden with holes given the number of files you can blindly call directly and have output things without error.

Hence the joke; Wordpress, built for people who know nothing about websites, by people who know nothing about websites.

... and I do compare it to the mysql_ function and how they are going to have to shove it down the web's throat by stopping security updates for versions that support it and making any code that tries to use it immediately bomb -- sometimes you have to walk up and smash in the window with a brick before people will actually bother fixing a crack. In that same way, there's a lot of things PHP is allowed to do that it just shouldn't be allowing in the first place.

Mind you, Python, Ruby and Perl have similar issues. Almost bad enough to make me long for the days of DiBOL and Clipper; which had more internal security and restrictions than any of these despite for all intents and purposes being intended for use as only allowing in two or three users at a time over direct LAN access.