Portal Home > Knowledgebase > Articles Database > Php - strlen security?
Php - strlen security?
| Posted by MatthewT, 06-21-2008, 03:44 PM |
| Hi,
Just a question regarding the security of using strlen in php, I've been doing a bit of searching and can't find a direct answer. Is it safe to use strlen on raw uncleaned user submitted data?
I white listed all allowable characters on all fields I take from users but when it comes to passwords I wanted to leave the possible characters they could use more extensive.
I have been considering using strlen on the raw inputted password first (e.g. strlen($_POST['password']) )to check if the password is of appropriate size. I then MD5 the password as a way of cleaning out any nasty injection and carry on from there adding salt etc. Is this safe? Is it possible for someone to inject something nasty that gets run when strlen($_POST['password']) gets run? Or is is possible for an attacker to submit a value millions of chars long that would cause the server to crash or something crazy like that?
(on a side note, is MD5'ing the submitted password a secure way to clean out any nasty attack from the password field?)
Any feedback appreciated, thanks.
Last edited by MatthewT; 06-21-2008 at 03:48 PM.
|
| Posted by Tree NC, 06-21-2008, 06:05 PM |
| I don't see any problems with using unsanitized data in a strlen() function.
Yes, MD5 hashes are quite possibly the most secure way of sanitizing data.
|
| Posted by MatthewT, 06-22-2008, 10:55 AM |
| Great, thanks for the feedback. Thought it was probably good, but wanted to make sure
|
| Posted by Steve_Arm, 06-22-2008, 11:00 AM |
| What do you expect from a password?
I usually let only numbers, characters and an underscore.
So with a reg ex pattern like this: [a-z0-9_]+ nothing can get in.
|
| Posted by Saeven, 06-22-2008, 12:47 PM |
| MD5 is not 'the safest' where semantics are concerned -- collisions are always possible. In fact, Microsoft has banned MD5 outright (as with DES, and MD4) from their development.
Vulnerabilities of the nature that you suspect, occur with input/output. The PHP platform takes the onus of hardening its own functions away from you, placing it onto itself. In and of themselves, the PHP functions are 'secure'; any less is considered a bug and needs fixing.
Your webserver would likely reject it (POST_MAX_SIZE, etc).
All authentication logic aside, assuming that you're using MySQL, it's perfectly safe to take any input with:
You're not outputting the data anywhere (there goes any output-based attacks, XSS, etc), you're thwarting any SQL injection attacks with the mysql_real_escape_string.
Here's an article that may help you understand attacks a bit better:
http://phpsec.org/projects/guide/2.html
Steve's suggestion is fine, but I'm of the belief that it's always better to let users pick whatever password they want. Most people have a select few passwords that they remember and reuse (however bad this may be) -- probably hate to commit another one to memory
Hope this helps!
Alex
|
| Posted by MatthewT, 06-23-2008, 09:53 PM |
| Thanks for the additional feedback. I'm completely paranoid about any input I get from users.
I've been trying to make sure even if someone figures out a way to get around mysql_real_escape_string that i still have a layer of protection. I was originally cleaning out anything except a limited set of chars from the password (as you suggest Steve), but for the password field in certain I really wanted to allow users use a wider range of chars than the limited few I was permitting (for the very reason you say Saeven of users re-using the same set of fixed passwords).
As it stands I am MD5'ing the password, then running that through a preg_replace allowing only A-Z,0-9 and then to be extra sure, running that through mysql_real_escape_string. I guess it might be a bit of an overkill but I'd much rather that than dealing with a successful attack on the site.
Thanks for the feedback.
|
| Posted by Saeven, 06-23-2008, 10:04 PM |
| Yea that's a bit paranoid hehe
You can rest assured that MD5 won't return anything outside of the alphanumeric realm. It's not overkill at that point, moreso a waste of bits and bytes
mysql_real_escape_string serves to protect you from SQL injection attacks. An attacker wouldn't be able to "get around" mysql_real_escape_string. If you insert unfiltered data however, what happens to it on the way out should be examined.
You don't need to double-up on methods really, just follow the good old rule: FIEO (Filter Input, Escape Output).
PHP5 gives you the filter extensions for this:
http://ca3.php.net/filter
Good luck!
Alex
|
Add to Favourites 
Print this Article
Also Read
Server setup (Views: 690)
Dell beast (Views: 704)
Shared Hosting
Shared Hosting
