Tag Info

Hot answers tagged

10

Oh yes it is! Consider this HTML: <a href="{{str}}"> and consider an input like: " onmouseover="alert('GOTCHA')" You get the picture. If your javascript is being injected within a tag then you don't need the angle brackets. I borrowed this off this similar S/O post: http://stackoverflow.com/questions/5696244/xss-is-escaping-and-sufficient ...


4

Google spends a lot of money each year in bug bounty to ensure that Gmail isn't susceptible to XSS. Part of this effort has produced Google-Caja, which is an open source project that filters HTML to a "safe" subset. HTML filter sandboxes like Caja rely upon an "older" solution that uses complex parsing techniques, and thousands of regular expressions to ...


3

Any error message shouldn't provide information to the attacker other than their attempt was unsuccessful. Example: A password/username failure should say the attempt was bad, not whether the username was bad, or the password, or both. If it does, that information might be usable to an attacker in an effort to circumvent your safeguards. Something along the ...


3

Well, even if Google was vulnerable to XSS, this still wouldn't be a breach. Why? Because of the HTTPOnly flag. It is the big reason for XSS's downfall. You can say there are two kinds of cookies: those that your browser gets when it recieves an HTTP response from a remote server (like google.com). They are in the Set-Cookie part of the response. ...


2

Given the fact that the hackers had access to the servers and their data, then they had direct access to the HTML files. Protection against such an attack is very broad in scope, because you have to protect yourself against all forms of intrusion into your network.


2

There is stored XSS and DOM based XSS which do not rely upon a GET parameter. POST based XSS is exploited using a simple cross-site post request, which can be triggered using the following HTML and JavaScript <form id=xss action=http://target/action method=POST> <input name=param3 value="'+alert(document.cookie)+'"> <input ...


2

The issue is if you accept user input as part of the url you output, as in this example given by OWASP: <a href="http://www.somesite.com?test=[user input]">link</a > The attacker does not have to break out of the URL context, but out of the string, eg by injecting: foo" onload="evilJS();" foo="bar or to break out of the a tag as well: ...


1

Never evaluate untrusted input as HTML. Even if the DOM is disconnected (i.e. not inserted in the document), evaluation of HTML can still cause XSS. Your specific example can be exploited using event attributes: var userInput = '<img onerror="alert(\'XSS\')" src="bogusurl:">'; $("<i></i>").html(userInput); If you really need to parse ...


1

As Desthro said, an error message should not provide too much info to an attacker. The recommended practice is to display a static error message that does not include any of the user-provided data. Your error message should say no more than about "Invalid characters in street address." If you want to be more helpful, you could be a bit more specific and tell ...


1

When it comes to Cross-site scripting, the most important thing is context. The context in which it gets reflected or stored.I will demonstrate this with a real example from my experience. Once while bug-hunting i noted that a URL parameter was getting reflected inside a variable: http://www.example.com/blah.php?id=test&var=101011 The value of var was ...


1

hope there is no one linking to a page with an advanced exploit kit or persistent xss vuln. The risk with shortened links isn't really persistent XSS, but reflected XSS and phishing. Let's assume stackexchange is open to persistent XSS. If I post a link to https://security.stackexchange.com/questions/414141/my-evil-question you would believe that it is ...


1

Generally speaking, no. CSRF protection and session authentication are typically supposed to be separate concepts entirely. The responsibility of a CSRF token is supposed to be a one-time key for a request - nothing more, while a session ID or session token is supposed to merely identify a user that has permission to perform the action in the first place. ...


1

An interesting one. If the CSRF token identifies the user as well, then I can't see it being a vulnerability in itself. Some systems can work without cookies (although you mention this one is designed to work with cookies) and can pass around an auth token in a hidden form field that is used as both a session identifier and an anti-CSRF token. In your case, ...


1

Wpscan wasn't able to reproduce this vulnerability so they removed it from the database. If you update the wpscan database with wpscan --update and then rerun wpscan against the url you're targeting you will notice the vulnerability does not appear.


1

Presumably it would need to not capture content loaded from other domains (like iframes or images), but that seems solvable. The easiest explanation is that for any feature to exist it has to be prioritized over all of the other features that don't exist. You have to sell it to developers and this seems like it would have privacy implications that would ...


1

The issue exists if the form is csrfable, then the attacker.com website can contain some JavaScript that makes a POST request to victim.com in order to exploit the xss. It is also exploitable through other means like a HTTP 307 response.



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