• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Web security


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.


Staff member
Maybe it's just me but that seems a lot of text lol :p

Now I'm assuming this is the 'sign up' process rather than the login as to be honest 90% of people would say sod it by the time they've got past page 1 only to find they need to input more data.... If amazon can get away with just a username and password I'm sure you can lol

So mad thought here - wouldn't it be easier to implement a login which has an email confirmation sent out which then has to be confirmed - think like most forums....

You could also supply a cookie which could maybe remove page 2, if the cookie is found it skips page 2. It could refresh every login and requires a page 2 login every 7 days or something just to limit the annoying aspect of logging in. Remember you want customers to come back, so things have to be suitable for normal people, not Jaz type people :up: :p

Also it looks like you've missed the auto log off function (although it could be in the mass of text somewhere) where it signs you out after x minutes inactivity or if you want to be annoying like a bank if you press 'back' key or go to another tab.


Active Member
No this is my custom CMS login screen, not the front end customer log in. I have a last activity variable set as well. Admins are customizable. Font end users I will probably lock at 15 mins inactivity. Banks are way too short I think.

I did think about the cookie, a session would be better, but the aim I am trying to achieve is to keep as much off the client as poss, cookies can be poisoned and such are not as reliable as a session, as long as the session is assumed to to be tainted anyway, depending on the input it receives that is.

Mmm.....I could add a cookie into the mix as well I suppose. Need to think on it.

Another honey trap idea coming to mind now, mmm......


Staff member
so let me get this right, this is basically to allow you and/or your business partner to login and do the behind the scenes updates/changes etc...

If that's the case, why not fix the login to your home ip address(es), this is of course assuming you have a fixed ip address (most decent isp's offer this for free) you could limit who can access the site without any complicated code :)

Or even better, make the home computer house a file that the webserver needs to access to load up step 2. I don't mean a cookie, I mean server loads stage a, looks for file A on your pc (set file location - ie C:\\jaz overkill\security.php), which then has the code that loads stage b on the server side again. Think of it as a remote key or license file where you can't get to stage b without having the file.


Active Member
Are you married, and would you do me the honour? (nod)


If that's the case, why not fix the login to your home ip address(es), this is of course assuming you have a fixed ip address (most decent isp's offer this for free) you could limit who can access the site without any complicated code
Ha, ha your such a kidda, with out it even on a static IP, aww dude you make me laugh. :D


Staff member
No worries, you know me I like to think a little (sometimes a little too much lol) out of the box from time to time :)

I'll see if I can come up with any more josm's for you although I'm not going to promise :)

for those that are wondering what josm means - it means Jaz's overkill security measures :p


Active Member
O Levi,
Your acronym doesn't make sense nor does it match the letters.
You meant to say: WSBSWDBP

Which everyone knows means

Then there wouldn't be any hacked websites in comparison to the 10k a week that currently are.
You will get your acronym's right one of these days, I'm sure. :D