laserlight, thank you for your reply. Yes, I'd like to prevent both http and https from being entered in the database. You say it's 'easy' -- but how would I do it. (I've been googling like crazy but not coming up with anything.)
Originally Posted by laserlight
preg_match() or even just stristr() could be used to check the content before saving it into the database.
laserlight, great! Thank you so much for your help.
Laser light is right. regular expressions are a bit hard to get use to at first but can save you a lot of time in parsing content. I suggest that you use something along the lines of strip tags as well. Remember to brute your regular expressions with all types of encoding, slashes, and quotes. Every time that you are grabbing any user input you should try to make the decisions all on your side and not so much the clients side. An example of this would be a list of files with check boxes. You could have the script send the file name through the post request, or you could make an index system where the file names are only important to you. This can help ensure that the content that is going into your database is exactly what it is meant to be. If your site has a lot of traffic and has any type of money exchange you should be making sure to pen test your site with a variety for open source tools. A fairly well known sql injection tester by the name of sql map can help you out. Do remember though if sql map doesn't find anything that does not me you cannot be exploited. Look into running background scripts or packet monitoring. A great method I have picked up in the time i'v known php is to have a form builder function which checks all incoming instead of individuality checks on incoming var.
No, I suggest that you don't attempt to strip tags, unless you are very sure that the format of the input is such that such characters that could lead to valid input looking like HTML tags are not allowed, otherwise you will end up corrupting valid input. Even then, it might be better to reject the input instead of modifying it.
Originally Posted by TylerDev
+1 with actually sanitizing and validating your inputs as appropriate rather than trying to find a blanket approach (because there isn't one; it's even worse than "jack of all trades, master of none" if you ask me). Simple example, say I come up with this rather secure password of " <mySuper$ecret>password", and say you fall victim of using some variant of garbage like:
Not only did you mangle user input, but you've now reduced my rather secure password to the word "password" for no apparent reason. (And I bet you didn't even admit to me in some sort of error/explanatory message, did you?!)
//prevent SQL injections and stuff and things
$password = trim(strip_tags($_POST['password']));
To avoid SQL injection attack you have to take one small step. You have to put White List Input Validation - Input validation is used to detect unauthorized input before it is processed by the application, thereby preventing the attack.*
Settled 4 red convertible
I'm afraid that you're making this sound a tad oversimplified. A whitelisting approach works Just Fine(tm) in some situations, but you can't make the jump that to "if you will just whitelist you'll be fine ..."
Originally Posted by annaharris
Not that you meant to say "if you just whitelist you'll be fine", but it kind of sounds that way in your post above.
This actually happened to me at a critical moment at work. Story time!
Originally Posted by bradgrafelman
We were dealing with this website that was constantly being hacked (garbage text was being injected into their site for Googlebots to find). Our client was becoming increasingly aggravated with us since we were unable to find the source (even though we encouraged them to upgrade their years-old Joomla! installation and they refused - basically they were blaming us). Eventually we took the "scorched Earth" approach and deleted everything on their FTP and reuploaded the files. We also changed all their passwords, including their control panel password. We have a password scheme but I made the call that it wasn't sufficient in this case and used KeePass' password generator to generate 40 character passwords of random letters, numbers, and symbols. The passwords are stored securely so no one has to remember them or even type them in.
I changed the control panel password without issue (a success message was posted after I changed it). After I recorded the password I went to log back in and my attempt failed. Tried again. Tried the old password, still couldn't get in. By this time I'm sure the hosting company had locked the account. The "critical moment" was that we were supposed to be done in about 15 minutes (the client's deadline), or the client was going to drop us. We tried contacting the hosting company but they couldn't do anything for us except send out a password retrieval email to whoever was on the account - which included the client contact we were dealing with directly (the one who gave us the deadline). So my boss had to call him and twist facts to try to keep the heat off us while getting him to forward us the password retrieval email.
I got the email and the password looked the same but was able to log in with it. I was perplexed, but on a tight timeline so I finished up my work and the crisis with the client was averted (kind of - payment is still pending). I went back and looked at the password that was in the email and noticed it was 1 character short - only 39 characters. Lining them up in Notepad I noticed the password that was in the email had a backslash stripped from it (forward slashes were okay). I relayed this info to my boss because I wanted to make sure he knew I didn't mess up. I couldn't believe it, though. This was a major hosting company (not GoDaddy) that we had used and still do use quite a bit. I sent a strongly worded email to them explaining the poor practice this was and the situation it had put us in. Never heard from them.
TL;DR: Popular hosting company stripped backslashes from their control panel password without notice and I couldn't get back in while in the middle of fixing our biggest client's website who was threatening to drop us.
So yeah. Absolutely do not do this. There is no reason to strip characters or otherwise change user-supplied passwords.
Declare variables, not war.
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)