Tag Info

Hot answers tagged

18

Try this: " onfocus="alert(1)" autofocus=" It will expand to: <input type="text" id="search-text" name="query" value="" onfocus="alert(1)" autofocus="" /> Which will cause an alert box, demonstrating XSS.


7

Src attribute could lead to XSS if you allow the user to define the protocol, for example to enter javascript: instead of http: Example: <img src=javascript:alert()> Additionally, you should use proper output encoding for the user controlled variables so that the user cannot escape out of the attribute/tag. For example if you have the following tag: ...


6

The class attribute could be used for redressing the UI to make untrusted elements and text appear to be authoritative text coming from the website itself. See the Google Browser Security Handbook for more information. Instead of writing your own, use an established HTML sanitiser such as Google Caja. These are hard to write because there are so many ways ...


5

As with all things in security, using HTTPS is a trade-off. You're trading some performance and potentially customer inconvenienace for improved security and other possible benefits (for example google boosting the ratings of SSL enabled sites). Only you can answer whether that's worth it, as only you know what your site does and whether the trade-off is ...


4

The impact of XSS is the same regardless of whether it is stored/reflective or DOM-based/server-side - the attacker gets full control of the web session. Stored XSS is more readily exploitable (you don't need to get a user to click a link) so it's more serious. Whether a vulnerability is DOM-based or server-side doesn't greatly affect the severity. You can ...


4

But that means that XSS is not for cookie stealing anymore? In short, no, XSS isn't used to steal cookies when this flag is set. The longer answer is that modern browsers support the HttpOnly flag on cookies. This flag can be set when the server sends a Set-Cookie header to the browser to keep document.cookie from getting the contents of cookies. It is ...


4

You must not rely on browsers respecting the content-type header for security. A quick look at CVE-2010-1420 should give you an idea. Content-sniffing mechanism implemented in browsers can be manipulated by attackers to trigger XSS attacks (Secure Content Sniffing For Web Browsers: A Survey). Survey of content sniffing behaviors According to this ...


3

If implemented correctly, HttpOnly prevents an attacker stealing the cookie. However HttpOnly feature can be bypassed in certain versions of some browsers and web servers. Take a look: https://lwn.net/Articles/646891/ https://www.youtube.com/watch?v=jrKOdWPZtAg https://bugzilla.redhat.com/show_bug.cgi?id=1222923 So in summary HttpOnly makes things ...


3

Yes, if the attribute is double quoted and you are encoding the double quote character, then it shouldn't be possible to escape from the quoted attribute. However, I would also encode the & symbol because that can be used to start an encoded character in itself. The HTML5 spec states: A double-quoted attribute value is specified by providing the ...


3

BeatifulSoap is not designed as a Sanitizer for HTML but primarily designed for extracting data from the HTML like needed in screen scraping. That is don't expect it to deal correctly with malformed HTML which nevertheless gets executed by the browser. Apart from that a large part of your question is already answered in your previous one. And to cite myself ...


2

This is not possible. It is not possible to manipulate an HTML form using JavaScript as far as file upload fields go. As noted the form must be submitted as multipart/form-data and the filename needs to be submitted as part of that: Content-Disposition: form-data; name="file"; filename="foo.exe" The value of an input with type file is readonly in ...


2

This sounds fine, and seems like a good solution to protect the session cookie against XSS attacks by duplicating the value of username into a non-http only cookie. All your authorisation checks should be being made server-side anyway. So if your client wants to do something server-side, it sends the request and then the server makes the authorisation ...


2

Well, the server HAS to set this flag on the cookie, if it doesn't, client side scripts such as javascript snippets in a XSS style attack can access the cookie contents. Also, you might want to look at XST(Cross-Site Tracing) which i believe can bypass this flag and allow stealing cookies in some scenarios. From the wiki page for it: Tagging a cookie ...


2

Stored or Persistent XSS is a kind of XSS vulnerability where the untrusted user input is processed and stored by the server in a file or database without any validation and this untrusted data is fetched from the storage and is reflected back in response without encoding or escaping resulting in permanent code execution at the browser whenever the stored ...


2

1- why there are html code if the browser will redirect it automatically It's traditional from the times where 302 was new and not every client understood what it means. It is not really needed today and uselessly wastes bandwidth. 2- if inject code in href, a javascript code can this executed before the redirection happened ? or not ? If you have ...


2

Judging by how alert(1);" onerror="alert(1); in the src attribute value got underlined I can guess that this is what you injected and that it is parsed as a string (you did not break out of tag value quotes). So there is probably no onerror attribute either, only value of alert(1);" onerror="alert(1); for data-mce-src attribute. To make sure, inspect the ...


2

With modern Intel CPU's (and we're talking 5-7 years now...) there is no significant performance hit on the computation involved in an SSL connection. So - from a performance perspective there is no reason not to use SSL everywhere. Another caveat is the vulnerability of mixed content on your page. You should not be referencing HTTP resources on an ...


2

XSS Even if we assume that your filters work perfectly (which I would not do automatically, filtering is rather complex, and easy to get wrong), this may lead to XSS. Because it hasn't been mentioned yet: a in combination with an unfiltered href is not secure, as JavaScript will be executed. An attacker can load a remote script and then redirect so the ...


1

To add to the existing answer: It might also possible to misuse the class attribute, depending on your code. Just imagine that your web application has some code which binds to any elements of a specific class or any which show a specific behavior (which can be set by the class). In this case this code could be triggered if you allow the user to use any ...


1

May be the most serious threat that an attacker can do with TRACE is to access document.cookie property in order to hijack the victim's session. TRACE won't work in any browser (luckily). For the case you described, it depends on the security layers implemented on the server the attacker runs it against and the question, as it is asked, is too broad to ...


1

The TRACE method is not issued by browsers for normal requests, that is you would need to do an XHR request or an HTTP request from a plugin or external tool. Since script is only executed by the browser when receiving a response to a normal GET/POST request executed by the browser for links, forms, script inclusion etc but not for manually generated ...


1

Your best bet is to probably not perform input validation, but perform some output sanitisation. A sanitiser such as Google Caja can be used to strip script before it is output to the HTML page. As there are often bugs found in sanitisers, often when there is a new addition or change to the HTML spec or implementation in a browser, it is recommended to ...


1

I'm of the opinion that you should filter (block) xss input AND escape user-supplied input on output. Why? Because databases are long-lived and often shared, so should not contain xss. And web applications often use more than one data source. If you're using Java, you can use Hibernate Validator with JSoup to parse and validate HTML input. It has a ...


1

By definition, the FHIR is asking you to preserve the XSS vulnerability of the data (store as code, display as code). XSS requires that the data be displayed back to users, which could be prevented with output validation, instead. Accept the input, store as JSON, filter when displaying the HTML data as HTML code. Depending on the "output" systems, this could ...


1

Though this being an old question, I'm adding an answer for future viewers. "Cross-Frame Scripting" is basically data leakage that can happen when an attacker embeds a victim's website into a frame within their own website and monitor/spy on the activities does on the framed website. An attacker can register a JavaScript listener which listens to all key ...


1

You should use URL encoding not HTML encoding. If you URL encode the back_url parameter the quotes shouldn't trigger any XSS warnings and you won't need to deal with converting them back and forth to make the redirect work correctly. Also be wary that this design introduces an open redirect vulnerability into your application. An attacker can craft a URL ...


1

XSS stands for Cross Site Scripting. So think about it, what is scripting? That's the noun form of the verb for the attack. You don't Cross-Site-Script (verb) unless you're attacking. It's not something you do to make a site vulnerable, it's something you do to compromise. Though as the marked-correct answer indicates, to be clear we should indicate which ...



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