Tag Info

New answers tagged

0

I can't tell you what will work because I don't have the application in order to test it myself. I can only suggest things you should try in your response. Try: HTML encoding " in the URL. Double URL encoding " in the URL (%25%32%32). Double URL encoding " in the URL (%2522). HTML encode then URL encode. Combinations of the above thereof. Try UTF-7 XSS ...


0

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 ...


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 ...


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 ...


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 ...


-1

If the user is authenticated and an attacker manages to use some kind of exploit to inject javascript (or flash) into the page, then yes, the attacker will be able to steal the secret token. They simply make a request using AJAX to the /auth endpoint and read the redirect URL that comes back. This was made possible recently by the addition of the responseURL ...


0

You can host all the phishing emails there. For example: We have detected suspicious behavior on your account. All furthur login requests will be denied. Please use the alternative login form at http://example.com/ to do a secure log in and unlock your account.


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 ...


0

You can checkout for this too ONLOAD=alert('XSS') Which will produce an alert box when the page loads.


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 ...


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.


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 ...


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 ...


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 ...


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 ...


0

Stripping out HTML tags is not a sufficient approach to protecting yourself from XSS. Consider the following input: <scri<script>pt> If you strip out the <script> tag, another script tag is created. This is just one example - there are many other attacks that could be used. You should look into protecting yourself from XSS on the ...


0

There are two main methods that are commonly discussed when dealing with user input. These two methods are validation and sanitisation. Both of these should be most definitely done on the server side. Client side protections will not prevent attacks such as cross-site scripting or SQL injection. In particular, I think you're talking about cross-site ...


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 ...


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 ...


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 ...


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 ...


0

When HTTP Only flag is set tot true on the server side then there is no other way to steal the cookie using XSS.In modern web browsers like Chrome there is no way to see the cookies using xss because the xss filters are enabled by default. If it is not enabled on the browser then there is also a way to enable the XSS filter in the browser from a server ...


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 ...


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 ...


0

I had to read your question a couple of times to understand what you were describing in option one - if your session cookie contains a predictable, clear text value (in your example the authenticated username and the redundant fact that they are authenticated) then your security is fundamentally broken. Session is should be random or encrypted with time ...



Top 50 recent answers are included