$passw= $ POST['passw']; is not safe

[rigaconnect]

Please, advice
Found information that $passw= $_POST['passw']; is not safe.
For example someone can input something like that x’ OR ‘x’='x
and make sql injection

However I tried to do it for my own website and get result that password is not correct. I use code like this: $passw= $_POST['passw'];

In many websites advice sanitize input removing "" <> $ etc.
And again. In qualitative websites tried to register username with such characters and the characters are allowed.

So the questions:
1) is $passw= $_POST['passw']; unsafe? If unsafe, then what code is safe?
2) is it necessary not to allow certain characters in username and password fields? If necessary, then what characters not to allow?

[swa66]

The problem you reference is known as SQL injection.

As such the code

$passw= $_POST['passw'];

is safe, but it al depends on what you do next with that $passw variable as it now contains unfiltered input.
If you filter it and/or escape it properly for your context -if you send it to a database at all - then it's OK.

So if you first look up the user in your database and get the hashed password and salt from there end then calculate the the hash of the salt combined with the password the user sent you, you're more than likely OK, allowing any character at all in the password (and even nearly any length).

If you however have a database and you look up if the password equals the one in the database and let SQL handle it all for you and you do not use prepared statements and use no escaping then yes: its going to be vulnerable.

Essentially:
- you need to filter input for things you do not want.
- if you use the obsolete mysql interface (and hence cannot use prepared statements) or even if you use mysqli and mix commands and data into one sql statement: then you need to properly escape the input.
- It's your job to do input filtering on any data coming from the browser. The best method is to consider it tainted till you know it is OK.
Eg.: if you expect an integer between 0 and 10, you need to be sure you're getting a number, it's in the range, it's not negative, it's indeed an integer etc.
There's 2 stategies: whitelisting and blacklisting.
whitelisting is more secure: you know all allowed inputs and match the input with what is allowed: once that done: you're sure.
blacklisting is much harder: you now need to know all input that your software cannot deal with safely. This is much, much harder to get 100% right. So security people prefer not to have this method used unless it is absolutely the only way.

Your reference to

"sanitize input removing "" <> $ "

is likely to be related to OUTPUT filtering: yes you need to do that too. any user input that is echoed back to a user is a potential for a vulnerability called Cross Site Scripting (XSS). It's not easy to understand it all as it would seem the only one who can exploit it is the user him/herself. But that as far from the truth as it possibly an get. An attacker can exploit the problem in a website to get to all your regular visitors if they find any XSS vulnerabilty anywhere on you domain/website. What you need to do is to filter HTML that might be in the input before outputting it back to a user (even if you stored it ...).

This filtering cannto be safely done at input time. It needs to be done dependent on the context of where the output is performed. The safe characters to output user input in e.g. a URL is different from what's safe in the body text of a html document.

Ref: Injection: [owasp.org...]
Ref: XSS: [owasp.org...]

[rigaconnect]

Thank you for answer

[incrediBILL]

Even simpler, if you don't store plain text passwords, the first thing you do is encrypt the password before making a SQL call which avoids the problem altogether.

However, the user name, email address or whatever else you use as the primary ID key can also be at risk without being filtered. Since email is very simple to validate, using an email address plus encrypted password makes it pretty safe.

[rigaconnect]

Am I correct?
If visitor in username field try to input something like <script>
then I need to make function that converts < to &lt;
and > to &gt;
So as a result visitor can use username <script>
but in mysql are entered &lt;script&gt;

[swa66]

NO!

You're mixing XSS protection - which you do at output time with what to do to avoid SQL injection at input time.

SQL injection:
It depends on how you use mysql (the obsolete mysql interface or mysqli (note the i) interface ?, and in the latter case prepared statements or not ?).
-> If it's not prepared statements than you need to escape things like quotes to avoid the attacker to terminate the data and continue with SQL commands themselves.

• mysql: [php.net...] (note it is obsolete, but that goes for all of the mysql functions)
  
• mysqli: [php.net...]
  
• prepared statements, when done correctly (not using user input while preparing the statement at all): you're safe from SQL injection

XSS
When outputting things entered by a user - it might contain things like html tags, script, quotes that terminate an attribute, etc.
So depending on the context (this is extremely important!), you need to use the right escaping.

E.g.:

• when outputting in the main body of html, you need to replace <, > and & with their html entities. A commonly used way (it really is overkill) is to use the PHP function htmlentities. Do not use this when outputtting xhtml5: it converts too much (xml only uses encodign for < > & ' and " , the others are illegal).
  
• when outputting an attribute (e.g. print('<div class="'.$var.'">' you need to be careful with the quotes (it could terminate the attribute and then add more attributes (e.g. an onload=... or termitate the tag itsefl and enter a new one ...
  
• when outputting a (part of) a URL, you need to URLencode it
  
• etc ...

Some places are very dangerous and require a lot of skill to properly escape it all. E.g. outputting data into javascript is tricky to say the lest.
Full list here: [owasp.org...] (scroll down to XSS Prevention Rules Summary, sorry this board eats the reference to it directly.)

[rigaconnect]

Thanks! Very good information for me... need to learn a lot