Jazajay
Active Member
Hi Guys and Gals.
Brain storm time.
Right my x, soon to be, wife and I have finally decided now we are no longer together that we are going to setup our own business, this time we have even both agreed on a theme. Honestly it's down to her being my x I swear.
So me being me and having knowledge of the CMS's out there have decided under no circumstances am I using any of them and I'll build my own, custom shopping cart, AJAX galore the works. Mainly due to the fact I end up rewriting shopping cart Payment integrations myself, manually fixing problems in old CMS versions and "working components" for work and I know how bad they are put together. i mean think about it they are put together for the average joe by normally the cheapest bidder, in my eyes and I have seen some awful coding and databases structured in an arse, about face way If any one has ever looked under the hood of any CMS out there you know how much of a mess it is.
So its taken me 5 days and I'm finally happy with the most important part of my CMS the back end login script.
However can anyone see any flaw in this, as I say 5 days on anything and I'm pretty sure any one would get tunnel vision and not see the obvious. Pretty sure I have covered all the security theory's to the letter.
The ones I include in the way I code are Defense in depth, Least privilege, Minimal exposure and Simplicity is best.
I also added a few of my own traps in, which I like to call honey traps that I have not found documented.
The reason why it has taken me so long to work on 1 script is because the underlying logic is now in place for the rest of the site, the login script is one of the most important areas if its not secure join one of the 10k plus sites that get hacked a week and your business has just gone down the toilet.
So if anyone can find any mistakes in this logic, improve it go for it. I just would like the feedback basically. There wont be any links given out for this for obvious reasons.
First off the screen itself.
Page 1:
requires case sensitive User name, email address and password.
Page 2 is a basic what is random number 1 + random number 2. Bot check if they ever got passed page 1. Did think about putting it on page 1, but that page was starting to get a bit too complicated for my own good so simplicity is best kicked in. Otherwise what tends to happen is a mistake occurs and the magnitude of the mistake is huge as a result.
So logic.
1) Max length is set on the from and checked on the 1st validation page. If this is exceeded the script goes to sleep for 10seconds and kicks them back to the login screen.
2) A custom error script is written and all warnings are removed from the scripts. No server errors are shown what so ever. All get stored to a file and are/will be checked daily.
3) All constant variables are set as environment variables and can only be called by the corresponding server super global array. Not in any code.
4) The email is tested for under a stringent test, if it fails the script goes to sleep for 10 secs and loads the login page.
5) The password is tested for invalid characters if it fails, you guessed it fails and sleeps for 10 seconds and loads the form.
If the data is vaild 2 tests are run. First strips out anything that is not a-zA-Z0-9 to nothing, well the script would then fail anyway, but it is then assigned another array to say it has passed.
This is then treated to a PHP safe guard function, redundant safe guard following defense in depth. Basically if I screwed up the main cleaning routine this would then make all data safe, not clean but safe. The only difference is this would pass validation and not kick the hacker back to the login screen, but the data is harmless.
All mysql data is again screened and assigned its own array to let me know its mysql output and again made safe.
Anything that doesn't have to be on the client is in sessions, ie no hidden forms input tags. This data is again then screened and assigned its own array before use/ other way round.
Sessions are set to keep track of the user and to remain logged in certain pages on the cms must be viewed before they can access it, a log in session is not good enough. This stops external scripts from sending data, as the script wont except it and send it back to my login screen where they have to play on my terms not theirs.
Tokens are used in the sessions and different per user and these are hashed and then rehashed with multiple algorithms.
SSL would be great, but not currently present, and not until the business can pay for it.
Now what I like to think as pure genius.
My honey trap (1st of many site wide).
I have saved in a html comment user: kjfkj pass: jkjkd email: khkjhk.
If anyone enters it it sleeps the script, displays a message saying this user no longer has clearance, and then just sends them on a loop outputting errors, same errors they would get if their data was actually being tested. When in fact there data isn't even being tested by the validation screen and never will for that session.
Think that's about it.
Can anyone think of anything I have missed.
O yeah forgot user who are submitting data to the database can only select data not add data to it, that's a different user group who does any inputting or updating to the DB.
Brain storm time.
Right my x, soon to be, wife and I have finally decided now we are no longer together that we are going to setup our own business, this time we have even both agreed on a theme. Honestly it's down to her being my x I swear.
So me being me and having knowledge of the CMS's out there have decided under no circumstances am I using any of them and I'll build my own, custom shopping cart, AJAX galore the works. Mainly due to the fact I end up rewriting shopping cart Payment integrations myself, manually fixing problems in old CMS versions and "working components" for work and I know how bad they are put together. i mean think about it they are put together for the average joe by normally the cheapest bidder, in my eyes and I have seen some awful coding and databases structured in an arse, about face way If any one has ever looked under the hood of any CMS out there you know how much of a mess it is.
So its taken me 5 days and I'm finally happy with the most important part of my CMS the back end login script.
However can anyone see any flaw in this, as I say 5 days on anything and I'm pretty sure any one would get tunnel vision and not see the obvious. Pretty sure I have covered all the security theory's to the letter.
The ones I include in the way I code are Defense in depth, Least privilege, Minimal exposure and Simplicity is best.
I also added a few of my own traps in, which I like to call honey traps that I have not found documented.
The reason why it has taken me so long to work on 1 script is because the underlying logic is now in place for the rest of the site, the login script is one of the most important areas if its not secure join one of the 10k plus sites that get hacked a week and your business has just gone down the toilet.
So if anyone can find any mistakes in this logic, improve it go for it. I just would like the feedback basically. There wont be any links given out for this for obvious reasons.
First off the screen itself.
Page 1:
requires case sensitive User name, email address and password.
Page 2 is a basic what is random number 1 + random number 2. Bot check if they ever got passed page 1. Did think about putting it on page 1, but that page was starting to get a bit too complicated for my own good so simplicity is best kicked in. Otherwise what tends to happen is a mistake occurs and the magnitude of the mistake is huge as a result.
So logic.
1) Max length is set on the from and checked on the 1st validation page. If this is exceeded the script goes to sleep for 10seconds and kicks them back to the login screen.
2) A custom error script is written and all warnings are removed from the scripts. No server errors are shown what so ever. All get stored to a file and are/will be checked daily.
3) All constant variables are set as environment variables and can only be called by the corresponding server super global array. Not in any code.
4) The email is tested for under a stringent test, if it fails the script goes to sleep for 10 secs and loads the login page.
5) The password is tested for invalid characters if it fails, you guessed it fails and sleeps for 10 seconds and loads the form.
If the data is vaild 2 tests are run. First strips out anything that is not a-zA-Z0-9 to nothing, well the script would then fail anyway, but it is then assigned another array to say it has passed.
This is then treated to a PHP safe guard function, redundant safe guard following defense in depth. Basically if I screwed up the main cleaning routine this would then make all data safe, not clean but safe. The only difference is this would pass validation and not kick the hacker back to the login screen, but the data is harmless.
All mysql data is again screened and assigned its own array to let me know its mysql output and again made safe.
Anything that doesn't have to be on the client is in sessions, ie no hidden forms input tags. This data is again then screened and assigned its own array before use/ other way round.
Sessions are set to keep track of the user and to remain logged in certain pages on the cms must be viewed before they can access it, a log in session is not good enough. This stops external scripts from sending data, as the script wont except it and send it back to my login screen where they have to play on my terms not theirs.
Tokens are used in the sessions and different per user and these are hashed and then rehashed with multiple algorithms.
SSL would be great, but not currently present, and not until the business can pay for it.
Now what I like to think as pure genius.
My honey trap (1st of many site wide).
I have saved in a html comment user: kjfkj pass: jkjkd email: khkjhk.
If anyone enters it it sleeps the script, displays a message saying this user no longer has clearance, and then just sends them on a loop outputting errors, same errors they would get if their data was actually being tested. When in fact there data isn't even being tested by the validation screen and never will for that session.
Think that's about it.
Can anyone think of anything I have missed.
O yeah forgot user who are submitting data to the database can only select data not add data to it, that's a different user group who does any inputting or updating to the DB.