xss attack

[orange08]

i just read some tutorial/information about xss attack, seem that it's very complicated...

 

currently, i just use htmlentities() to prevent this xss attack, is this sufficient enough to prevent it?

[gr1zzly]

I've had similar questions with my first serious php project, a blog style site with a mini bespoke content management system.

 

Best to use php's built in function strip_tags() although htmlentites() will render any html inert.

 

Here''s a really helpful guide for security issues

http://php.robm.me.uk/

[orange08]

I've had similar questions with my first serious php project, a blog style site with a mini bespoke content management system.

 

Best to use php's built in function strip_tags() although htmlentites() will render any html inert.

 

Here''s a really helpful guide for security issues

http://php.robm.me.uk/

 

thanks for the link, i will check it. 

 

other suggestions and opinions are still welcome...

[orange08]

from here

http://en.wikipedia.org/wiki/Cross-site_scripting

 

more i read, more confuse...

 

before this, i thought xss attack is mainly from html or javascript code, so htmlentities() can convert and prevent the attack...

 

but, from the above link, seem that most of the xss attack can just come from a URL sent by the attacker, so how htmlentities() can prevent it?

 

please help me to clear my confuse...i'm blur now with what is xss attack actually...

[micmania1]

Anything passed to a URL which is not part of a filename/directory must be handled by $_GET (or .htaccess which is another story).

 

You can use htmlentities($_GET['var']); its when you forget to validate your $_GET and process them that it becomes a vulnrability.

 

Please note that the above are all opinions and somebody may know better

[orange08]

the following is a case i found online, explaining how xss works...but, i'm not too understand...can experts here guide me to understand it?

 

Suppose that an attacker wants to gather info on a user of a fictional, popular banking Web site, www.simplebank.com. To log into the Web site, the attacker first enters a test user ID ("test") and password ("test"). When the resulting error page comes back with a message that says that the user ID and password combination is wrong, the hacker finds himself in an ideal situation for inserting malicious code into the Web page. How?

 

    * He first enters the following into the ID text box: <script>alert('Test')</script>.

    * He submits the form and then sees this JavaScript alert message: "TO BE DONE." Now he knows that the site is prone to an XSS-style attack.

    * He then might introduce scripts like those in Listing 1 into the URL that redirects the submitted user information to malicioussite.com.

 

      This code basically passes the user ID and password information of any user logging into the Web site along to the Web site of the attacker.

    * Now that the script to hack the user ID and password is ready, the attacker sends e-mails and posts with attractive offers to banking Web site users employing this link.

    * Prompted by the attractive offers, users might click on the link and log on to the banking Web site. The malicious script introduced by the attacker is executed by the browser and the data is passed to the hacker's Web site. The rest is a cakewalk for the hacker to log on to the banking Web site with the victim's credentials.

 

 

my first question is how does the attacker know the user's email, then send them email, stated in point 4?

[keldorn]

Cross site scripting is when they pass some crap in your url like

search.php?var=<script type="text/javascript">alert("lol xss!");</script> 

 

If you do not validate this input, then on the return page. Depending how your script works, say you might takes the input and place it in your html like

 

Here is the results for your search of: <script type="text/javascript">alert("lol xss!");</script>

 

Since that is real javascript, it will execute on the page. Now you have been haxored.

 

 

Secondly if PHPFreaks forum did that validate that. Right now you see a alert box saying "lol XSS!". 

 

Another thing. If someone can get real HTML/javascript into your page. They could steal cookies and all kinds of nasties.

 

 

[orange08]

Cross site scripting is when they pass some crap in your url like

search.php?var=<script type="text/javascript">alert("lol xss!");</script> 

 

If you do not validate this input, then on the return page. Depending how your script works, say you might takes the input and place it in your html like

 

Here is the results for your search of: <script type="text/javascript">alert("lol xss!");</script>

 

Since that is real javascript, it will execute on the page. Now you have been haxored.

 

 

Seconldy if PHPFreaks forum did that validate that. Right now you see a alert box saying "lol XSS!". 

 

if my search.php page did not expect any input from user, is that the attacker able to put some input in the url?

[Psycho]

my first question is how does the attacker know the user's email, then send them email, stated in point 4?

 

He may not know - specifically. I currently have hundreds of emails from "Bank of America" that were trapped by my company's spam filter. All of them are asking me to log in and verify information, get a free upgrade, etc., etc. However, I am not a customer of Bank of America. The a**hole sending those emails is simply spamming as many email addresses as possible in hopes that some will click the links and attempt to log in.

 

The internet has made this type of scam very cheap and easy. If a spammer gets only .01% of people to actually fall for the scam and he sends emails out to 1,000,000 people, then that would equate to 100 people that he now has their banking login credentials.

 

The solution is simple - always validate/cleanse ANY user input. This includes POST, GET & COOKIE values. If the value passed in a URL/form/cookie is supposed to be an integer, then make sure it is. Always use mysql_real_escape_string() on anything used in a query. The bottom line is never trust anything - if I save a user submitted value as a session variable I will validate before saving and when retrieving it - because I'm that anal about it.

 

I'm by no means perfect, but the problem I see all the time is where people think that they are "hard coding" the value for the user to select, so they don't include any validation. One example would be a link to a "profile" page which passes an ID in the URL. Since the developer creates the links for the user he may think he doesn't need to validate the ID, but the user can type anything they want into the address bar. Another one is select lists. I've seen some people who think that they do not need to validate select list values because the user can only select the values they give them, right? That is unless the user creates their own form to post to the site.

 

For me the problematic issue is what to do with user submitted data that gets saved to the database which 1) can be displayed in HTML content and which 2) can be edited by the user. In these situations I prefer to save the content as-is to the database (using mysql_real_escape_string(), of course), but to then use htmlspecialcharacters() or some other method when displaying the input to the page. That way if the user needs to modify their content, I can repopulate a textbox/textarea with the original content. If you use htmlspecialcharacters() before saving to the database, the text may be unusabe for editing. The bottom line is to always think about how the data is going to be used and to validate and cleanse it appropriately.