The problem you reference is known as SQL injection.
As such the code
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.
- 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