Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am using Netsparker community edition for checking my app for any general security holes. I'm getting a lot of following XSS probable issue areas:

my_php_file.php?nsextt=" stYle=x:expre/**/ssion(alert(9)) ns="

Code in my_php_file.php is not accepting any $_GET or $_POST parameters.

So how I am supposed to fix this sort of XSS problems if I'm not even using those $_GET or $_POST parameters?

Also in pages where I do use $_GET params I get this:

my_php_file2.php?id=" stYle=x:expre/**/ssion(alert(9)) ns="

I do filter all incoming params (for example id from last snippet):

trim(htmlspecialchars($_GET['id']));

And after all that I even run result of previous in preg to allow only digits in that id param.

Could someone would so kind and advise me what those XSS alerts are all about? How to approach them?

share|improve this question
3  
strip_tags does not filter ". Please note that expression() only works on Internet Explorer. But in this case you can use 1" onmouseover="alert('XSS'); for cross browser compatibility. –  Hendrik Brummermann May 11 '12 at 7:39
1  
Are you using the REQUEST_URI server variable? Putting that unescaped in a form action is a common error. –  bobince May 11 '12 at 11:20
    
@bobince i do not use REQUEST_URI at form action, but i do use it it in my functions file that i use it for manipulating current URL pastebin.com/Mzrfjj7F –  arma May 11 '12 at 13:26
    
Don't encode/filter incoming data, encode it where it is used. That's the only point where you can know what kind of encoding is required. –  CodesInChaos May 11 '12 at 13:59
1  
@arma: then you would have to use htmlspecialchars() on anywhere you used the output of that function. Indeed, as per DW's answer, you should in any case be using htmlspecialchars() any time you put text content into HTML output, rather than trying to handle at the input stage. –  bobince May 15 '12 at 11:47
show 1 more comment

3 Answers

up vote 5 down vote accepted

I suggest you read about defending against XSS. OWASP has good resources. You need to apply proper input validation to all input values, and properly escape all dynamic values that you insert into the output HTML document. There are many online resources on how to prevent XSS.

As far as your specific application, you haven't provided us enough information to diagnose the issue. Did you try opening my_php_file.php?nsextt="..." in your browser, to see what happens? Does an alert dialog pop up? If you view the source of the response, do you see a "style=..." attribute anywhere in the response? Also, though you say you don't use any GET parameters in my_php_file.php, is it possible that code in my_php_file.php might include another PHP file or might call some other function that produces unsafe output? I suspect you may have an XSS vulnerability that allows injection of a new attribute into the middle of some attribute list somewhere.

You mention the approach you are using to sanitize the parameters on other pages. I'd like to mention that this is not the proper input sanitization method. strip_tags does not prevent XSS (strip_tags is not guaranteed to remove all tags; and even if it did, removing all tags is not sufficient, as one can still mount an XSS attack by injecting attributes without injecting any new tags). A good rule of thumb is that if you're using strip_tags, you're probably doing something wrong.

More generally, input validation is not about blindly throwing every stripping function you can think of the data. Instead, you should check that the input matches a suitable whitelist or regexp, as appropriate for the type of the data. And, when you output the data, you should escape it in a way that is suitable for the context where the data will be inserted. For instance, if you are inserting it into the standard between-tag HTML context, you can escape the data with htmlescapechars. If you are inserting it as a link (as the value of a href attribute), then you need to ensure that it is a properly formatted URL with a safe scheme (http or https are safe; javascript is not). There's a lot more to say about input validation and output escaping: see the OWASP resources for a lot of great information on this topic.

share|improve this answer
    
About data sanitization i totally agree and i should review my app with more careful sanitize. But anyways at the end i still do hard preg check only for digits 0-9 only, if it's something else it won't accept it. Theres no single user input in my script that is not filtered. I'm more leaning to the part where i have made some XSS ways via my own code - for example check @cx42net comment i made. –  arma May 11 '12 at 7:56
    
+1 for input validation clarification. strip_tags is useless and HTML-escaping at the input stage is very the wrong thing. –  bobince May 11 '12 at 11:22
add comment

For your first question, if you sure about your code not using $_GET or $_POST, then you should be fine. But are you using a framework or some other code ? Have you tried to access my_php_file.php?nsextt=hello%20world and search for "hello world" in the source? Maybe you forget some include that use $_GET['nsextt'] ?

(note : by passing var via the url in a browser, only $_GET will be used.)

Now, for the second part, instead of all those functions + preg to check if the input is an int, you should use the filter_var() functions in php :

$secure_integer = filter_var($_GET['id'], FILTER_SANITIZE_NUMBER_INT);

If you want, you can also just validate the input with FILTER_VALIDATE_INT instead of FILTER_SANITIZE_NUMBER_INT.

share|improve this answer
    
Thanks for pointing out filter_var function. I use custom made cms. If i run any of XSS example stuff in my URL it will add to language switcher links. Was before - register.php?lang=en, after - register.php?lang=en&nsextt=hello world. I made that so i can switch languages and stay on same page where user was before (for example this: register.php?lang=en&page=123). –  arma May 11 '12 at 7:50
1  
I understand, but does nsextt have an impact in your resulting html ? (search for the "hello world" string in the source, do you find it ? can you change it via the url?) –  Cyril N. May 11 '12 at 8:07
    
other than that appended part to my language switcher theres no more mention of that string in html. –  arma May 11 '12 at 13:15
    
As i expected - my language switcher script was not correctly sanitazing data. Fixed now. –  arma May 13 '12 at 12:18
add comment

use this library to protect you against XSS attacks Google Code PHP-antixss and also their is a PHP functions called htmlspecialchars() that will help you a lot and you should know about it ,you can use OWASP XSS prevention cheat sheet as a guide also

share|improve this answer
    
Thanks great to see some nice scripts. For the form data i also use this library: svn.liip.ch/repos/public/ext/externalinput/trunk/lx/… –  arma May 12 '12 at 17:01
    
@Bnhack - as per my comment on one of your other questions - you need to post answers, not links to elsewhere. Please feel free to update your answer to improve it. –  Rory Alsop May 13 '12 at 18:11
    
you mean this is not an answer ,then how should i answer –  Bnhack May 13 '12 at 20:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.