Jump to content

UTF8 and PHP Security issues


ajoo

Recommended Posts

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.

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

  • Like 1
Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.