ajoo Posted November 26, 2014 Share Posted November 26, 2014 Hi everybody ! Am back with the never ending security issues, just that this time it has to do with the character set related security issues. I read the whole day on utf-8 and am still lost on certain aspects related to PHP security. Consider the simple script below: <?php //error_reporting(E_ALL & ~E_NOTICE); session_start(); if(isset($_POST['login'], $_POST['password'])) { $login = $_POST['login']; $password = $_POST['password']; if(!empty($login) && !empty($password)) { //echo "Ok"; echo "Welcome ". $login; echo "<br> You password is.$password "; } } ?> <html> <body> <form action="welcome2.php" method="post"> Name: <input type="text" name="login" /> Password: <input type="password" name="password" /> <input type="submit" name="submit"/> </form> </body> </html> It is not a login script, but assuming that it was one, I would like to know that if UTF-8 was the charset that was selected for this script, then : 1. how could it be exploited to pass a string that would effectively break thorugh this login. It would be great if someone can demonstrate the hack using the above script example. 2. Could the same be thwarted by the use of input filters? 3. I also read that the use of a regex to limit the use of special characters in passwords is not good . So in case the hack can be thwarted by the use of regex and that is a bad idea in the first place what should be done? There are a few more questions that are on my mind but I would only ask those once I am clear on these that I have just asked. Thanks all. Quote Link to comment https://forums.phpfreaks.com/topic/292732-utf8-and-php-security-issues/ Share on other sites More sharing options...
Jacques1 Posted November 26, 2014 Share Posted November 26, 2014 None of this makes a lot of sense. First of all, how did you come to the conclusion that there's an encoding-related security issue? Who told you that? Where did you read that? Secondly, the script doesn't really do anything, so how would an “attack” even look like? We cannot “attack” hypothetical code which isn't actually there. There is a problem in your code, but that has to do with the total lack of any HTML-escaping. If you just dump the user input into the HTML document, then of course anybody can inject malicious code. Quote Link to comment https://forums.phpfreaks.com/topic/292732-utf8-and-php-security-issues/#findComment-1497750 Share on other sites More sharing options...
Psycho Posted November 26, 2014 Share Posted November 26, 2014 I think you are mixing up sanitizing and validation. People may argue on the actual terminology, but here is my explanation. Sanitizing is the process of escaping data that could otherwise cause errors (SQL Injection, XSS, etc.). Validation is the process of verifying data is appropriate for its intended use. For example, if you store a value for "age" a value of "blue" would not be valid. You could still store that value if you wish - proper sanitizing would likely convert it to a 0. What you are describing seems to be adding validation logic to prevent possible issue with sanitizing. You should always implement best practice around sanitizing data. Validation logic should be based upon the business rules. Not allowing special characters in a password is a horrible idea. Dictionary attacks primary focus on brute forcing "words". That is why people are encouraged to use 'complex' passwords: upper case, lower case, numbers & special characters. If you limit what can be used, then you are effectively reducing the possible combinations that would have to be used to try and infiltrate a users login. 1 Quote Link to comment https://forums.phpfreaks.com/topic/292732-utf8-and-php-security-issues/#findComment-1497752 Share on other sites More sharing options...
ajoo Posted November 26, 2014 Author Share Posted November 26, 2014 Hi Jacques, I am sorry, I think I mixed up the issue of mysql_real_escape_string with the utf-8 character encoding, the two issues that I read about today. As for the other errors in the script, I am aware of them. Thanks for the reply and sorry for this mix up. Quote Link to comment https://forums.phpfreaks.com/topic/292732-utf8-and-php-security-issues/#findComment-1497756 Share on other sites More sharing options...
ajoo Posted November 26, 2014 Author Share Posted November 26, 2014 Hi Psycho, Thanks for the response. Yea I am all mixed up reading security and related stuff, especially the ones you mention - sanitization and validation. I just mixed two issues by mistake. What I wanted to know was ( with an example) that if there can be security issues related to using a particular character set like UTF8. Any particular precautions that need to be taken when using UTF8. If there are any then please let me now. Thanks for the reply. Quote Link to comment https://forums.phpfreaks.com/topic/292732-utf8-and-php-security-issues/#findComment-1497760 Share on other sites More sharing options...
Jacques1 Posted November 26, 2014 Share Posted November 26, 2014 The mysql_* functions are long dead and will be removed from PHP in the near future. Manual SQL escaping is generally obsolete, we use prepared statements now. With prepared statements, you don't have to worry about SQL injections -- as long as you pass all values to the statement parameters and never insert them directly into the query. Note that if you use the PDO database extension, you have to set the PDO::ATTR_EMULATE_PREPARES attribute to false to get actual prepared statements. Otherwise PDO will only do a kind of auto-escaping (which is much less secure). 1 Quote Link to comment https://forums.phpfreaks.com/topic/292732-utf8-and-php-security-issues/#findComment-1497761 Share on other sites More sharing options...
ajoo Posted November 26, 2014 Author Share Posted November 26, 2014 Hi Jacques, Thanks for that information. I use the mysqli as of now. I have to read up on PDOs. Will be a while before i use them though. I'll bear in mind this piece of information. Thanks. Quote Link to comment https://forums.phpfreaks.com/topic/292732-utf8-and-php-security-issues/#findComment-1497766 Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.