cross-site scripting (xss) attack

I just have one simple question about XSS attack. I know that you can prevent them by sanitizing the form inpu开发者_开发知识库ts, but my question is, how about a search input (a general search on a website for example)? Should we sanitize search inputs as well? I mean, it's just a search input, the user should be able to search for anything that he/she wants on the website. Please provide me with some clarification on this.

Thank you

I know that you can prevent them by sanitizing the form inputs

nope, you should prevent them by sanitizing the output. So in database (or wherever) you need to pass the data as-is, and process it right before you show it to user

Tho this has already been answered by zerkms

Doing sanitizing on sql injections from any user input that touches the database requires mysql_real_escape_string($_REQUEST['search'])

On output if your showing what user searched for like "You searched for:" use htmlentities(strip_tags($_REQUEST['search']), ENT_QUOTES);

Then your safe from incoming and outgoing

I just want to add one more point to the discussion here. You said:

I mean, it's just a search input, the user should be able to search for anything that he/she wants on the website.

Here's the gotcha: frequently the search term will be printed into the document that's rendered following the search. Ie, "You searched for: <whatever is was>". That's where you'll have your XSS vulnerability if you're not sanitizing this stuff.

If you're thinking "but we don't do that", bear in mind that you may not do so now, but you might do so in the future. And if you don't seal off this vulnerability now, you're likely to forget to do so later - so it's best just to nip this one in the bud.

how about using htmlpurifier ?

SQL Injection and XSS are two different (yet somewhat related) attacks. They are related in that essentially it boils down to the untrusted data escaping from the context it was placed in and subsequently performing unforeseen operations.

For following best practices in building your defenses I recommend having a read through OWASP's SQL Injection Prevention Cheat Sheet and their XSS Prevention Cheat Sheet.

OWASP has put forth the ESAPI Project which includes tools for encoding for the different contexts in which untrusted data can be used:

• encodeForSQL
• encodeForHTML
• encodeForHTMLAttribute
• encodeForJavaScript
• encodeForCSS
• encodeForURL

This library is available for a number of languages including Java, .NET, PHP, Classic ASP, Cold Fusion, Python, and Haskell. It also is able to perform input validation if it's required.

Some organisations who are using ESAPI include American Express, Apache Foundation, Booz Allen Hamilton, Aspect Security, Foundstone(McAfee), The Hartford, Infinite Campus, Lockheed Martin, MITRE, U.S. Navy - SPAWAR, The World Bank, SANS Institute.

Lastly - the encoding is to be performed just before interpretation (the closer the better). Ex: Just before you give the UI component the untrusted data to render you encode it. The UI component can't trust the server - it has to encode.