Hot answers tagged

133

A good option is to harden your Content Security Policy. It allows you to fine-tune which resources the browser will load/run, and is supported by most browsers. Consider the following header: Content-Security-Policy: default-src 'none'; img-src 'self'; style-src 'self'; This tells the browser to disable scripts, frames, connections and any other objects/...


17

Did XSS reach its end-of-life with the introduction of the HTTP X-XSS-Protection header? No. X-XSS-Protection is only used to enable or disable the inbuilt filtering[*] - which is generally enabled by default anyways. So a more fitting question would be if XSS reached its end-of-life with browser filters. But again, the answer is no. XSS is still a ...


12

Thanks Alexandar O'Mara for pointing me in the right direction - it was a small tip, but it got me there. I ran nslookup with the domains and got: C:\Users\xxx>nslookup scorecardresearch.com Server: router.asus.com Address: 192.168.56.1 Name: scorecardresearch.com Address: 103.16.230.165 C:\Users\xxx>nslookup sb.scorecardresearch.com Server: ...


8

Are there any caveats to this approach? (security-wise) Yeah, it's not very thorough, you can get a new instance of the constructor from a new window object instead: XMLHttpRequest = null; var iframe = document.createElement('iframe'); iframe.style.display = 'none'; // optional document.body.appendChild(iframe); var XHR = iframe.contentWindow....


6

If you look at the page source, there is a JavaScript function rwt() executed on onmousedown event. <a href="http://security.stackexchange.com/" onmousedown="return rwt(this,'','','','1','AFQjCNHano0MrEGop-Wp0eV_bNhmdh7OtQ','H4np7JuYNqsCuTIjB-78Eg','0ahUKEwjzldecwZfNAhWEVxoKHX8OAnwQFggdMAA','','',event)"> Information Security Stack Exchange</a>...


5

The first line 'iayQS28R... is a key to be XORed with the bytes given in the code variable. When interpreted by Javascript, it does nothing because it's just a string constant. But the script opens its own source file (something you can't do in pure Javascript, but you can with the extra packages that are available when Windows runs a Javascript script as a ...


5

Are there any frameworks that work this way? Sure. Twig or Django would be two examples. The inverse of this is clearly a far more secure default, ie. all dynamic data is escaped, unless you specifically tell the framework not to. Yes, this is a lot more secure. Is there something I'm missing? The one downside is that XSS is context-sensitive....


4

Parsing BBCode in a safe way that does not open the doors to XSS hell is a tricky task, and there have been many failed attempts. As you yourself note, the way you currently do it is vulnerable to XSS - all you need to do is post [script src="evil.js"]. Just using htmlentities() will not solve this for you, it is much more complex. This blog illustrates the ...


4

This does not look exploitable to me. The only user input here is the location variable. However, it is only used to check if the protocol is HTTPS or not and then change the URL of the included script accordingly. There is no way to sneak any parts of the URL, like a query parameter, into g.src. Also note how it is constructed through concatenating hard ...


3

What are some reasonable/interesting ideas of ways to address this issue practically? GPG encryption, with steganography to hide the fact that you're using encryption in plain sight. The basic idea you need to avoid mandatory compromise to encryption, is find any data channel that is not blocked and use non-compromised encryption over that data channel. ...


3

You can use a CSPRNG for the IV. This can be stored next to the encrypted text. The IV does not need to be kept secure, it just must be random.


3

The most important thing to consider here is that this type of JavaScript malware does not run in a browser. It runs in a special runtime called NW.js which gives powerful NodeJS API's not found in a browser. While NW.js shares many technologies with the Chromium browser, it is not a browser but a type of native wrapper for making desktop apps, and this ...


2

Nope, no software exploits, just classic exploitation of dumb users. The payload is distributed in a self-extracting RAR file. A self-extracting RAR file is really just an executable extractor with the .rar file appended to the file. Such a file is an executable file with the .exe extension, and has a feature to run arbitrary code after extraction. The ...


2

This is not Javascript breaking out of a browser's vm/sandbox but rather an executable that runs with full local user privileges that happened to be written in Javascript... There's nothing to harden as local Javascript app platforms like NW.js are designed to allow exactly that and like all other platform/frameworks they can be used for good as well as for ...


2

Even if this would work and you could block JavaScript from performing XMLHttpRequests - which as shown by @Alexander is not the case (ActiveXObject would be another alternative) - it doesn't really limit the dangers of XSS. An attacker still has a number of possibilities: Defacement Phishing: For example, add a login form, which sends the entered data ...


1

There are two parts on http://stegosploit.info/ The first one is about hosting the javascript exploit in an image file loaded through canvas. As such, it's not really interesting since in order to be exploited, the attacker would already need to be able to insert javascript into the webpage. The second part involves also including the html into the image ...


1

To answer the question: The website admin must be in on the exploit. The encoding technique is there to obfuscate the actual exploit scripts, thus flying under the radar from current detection methods. It still requires HTML/Javascript to be on the webpage in order to decode and run the exploit. That is to say, if I had encoded an exploit into ...


1

Yes, it is a problem, maybe even a big problem, but "XSS" probably isn't the right term. What could possibly go wrong? remote code execution using svg, especially older browsers off-site images leak your user's IP address (aka lat/lon), userAgent, and net performance malicious images themselves been vectors, lots of 0days in the past A special or even ...


1

No, in modern browsers no XSS is possible via the style or src attribute of an <img> tag. So neither of these would execute the JS code in any up-to-date browser: <img src="javascript:alert(1)"> <img src="x.jpg" style=background-image:url('javascript:alert(2)')"> Support for Javascript in CSS attributes has long been abandoned. You can ...


1

This appears to be the same as CSRF, except that the payload is executed by JavaScript. Because X-Frame-Options is set to prevent framing, the JavaScript can only be executed if the GET request is opened in a new window (or tab). <img> tags won't work because any HTML or script returned in the response won't be interpreted by the browser. If your ...


1

There are multiple reasons for this (sending data all over the place). If you are phishing with the intent of exploiting something, you may have something like mod_redirect running in the background to target specifics. E.g.: if UserAgent = IE && Windows 7 then send them to this particular page with Win7 IE specific exploits or if UserAgent = ...



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