Hot answers tagged

32

XSS is a form of code injection, i.e. the attacker manages to inject its own malicious code (usually JavaScript) into trusted code (HTML, CSS, JavaScript) provided by the site. It is similar to SQLi in that it is caused by dynamically constructed code, i.e. SQL statements, HTML pages etc. But while there are established techniques to solve SQLi (i.e. use ...


21

It seems easy, but is hard First of all, the attack surface is huge. You need to deal with XSS if you want to display user input in HTML anywhere. This is something almost all sites do, unless they are built purely in static HTML. Combine this with that fact that while XSS might seem easy to deal with, it is not. The OWASP XSS prevention cheat sheet is 4 ...


7

My set of opinion on security and XSS: Rule of programming: You can't know everything. Sooner or later you are going to make a mistake. Rule of programmer: A programmer works 12h a day: 3 is discussing with other programmers random things, 3 is thinking at other things, 3 is discussing on what it should code, 3 it's programming .... projects are made for ...


6

As mentioned in the answer to a similar post of yours (SQL injection is 17 years old. Why is it still around?): There is no general fix for SQLi because there is no fix for human stupidity Developers sometimes get lazy or careless and that causes them to not check the application they are developing. Another popular reason is that the developers aren'...


6

If you tightly adjust your WAF to your application so that it can fully distinguish valid from invalid input for specific input fields than you should be able to detect attempts to inject persistent XSS through the use of input fields. But, usually WAF are not adapted that tightly to the specific application and in this case only employ some heuristics to ...


5

I'd suggest that trying to apply numeric values to abstract constructs like "risk", "impact" and "likelihood" isn't likely to be a great idea. The problem is that each of these terms tends to be both subjective (what's likely to one person isn't likely to another) and extremely situational (the impact of XSS on one site will be likely different to another)...


5

An XSS attack could replace a legitimate download link on the site to one that contains a trojan. The user clicks the link, downloads the executable and runs it thinking it was the genuine program they were intending to install. The attacker could even backdoor the original executable so the user doesn't suspect that anything is wrong. As for user files, it ...


4

The user can modify and delete anything stored in their browser. Any malware installed in the user's system with the user's privilege can also do so. The system administrator can also modify and delete anything stored in any user's browser. Any malware with the administrator's privilege can do the same. Another non privileged user in the same system ...


4

To cause injection in this context you need to either: Close the script tag: e.g. </script><script>alert('xss'); OR close the single quote string context: e.g. '; alert('xss'); However, as the first option would result in &lt;, etc, and the second option would result in \' characters being output (and not possible to escape \ either ...


4

However, it would still be possible to alter the data on the screen in unexpected ways, and possible to create a convincing Phishing scam by providing a link out to another website. Is this accurate, or are out-links prohibitable also? Yes it is accurate with one caveat: people on your site run modern browsers. For this exact reason, my team ...


4

The root problem The web was simply not designed to allow secure multi-authorship or rich interaction. Nobody talked about separating content from presentation until the late 1990s. By that point, like the QWERTY keyboard, we were basically stuck for no good reason with an existing system. Nobody wanted to "break the web", so mistakes were copied and ported ...


3

No. XSS makes it possible to run Javascript in a browser of another user. This makes it possible to do request on behalf of that user. Since the code is only run in the browser, you cannot use PHP code. If you have XSS and you want to run code on the server, the best approach would be to steal the cookies of a logged in administrator using XSS, and use the ...


3

Others have touched on the classic issues surrounding systems designed by humans for other humans: The reality is laziness and—sometimes—stupidity coupled with “Why would this happen to me?” arrogance. Oh, how many hours of my life have been spent patching systems and—more importantly—fighting with management to get the time/resources allocated to patch ...


3

This is reflected XSS, not DOM-based XSS. The difference is subtle, but here are the key sentences. OWASP - DOM Based XSS the page itself (the HTTP response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment. A classic example: <...


3

Original version Using document.write in an event can cause problems is the event is fired after the page is loaded (i.e. closed), because the browser will then clear the document and start a new blank one. I am not sure I understand what the "payload ain't delivered clean, as result I get a lot of other HTML mixed" is supposed to mean, but this might be ...


3

I think that the point isn't phrased ideally, as a WAF can indeed catch some persistent XSS attacks. But there are at least two problems: persistent XSS attacks do not just happen via web requests, but could happen via a variety of other means, such as email. The vulnerability is really only introduced when data is read from the data storage - eg the db - ...


2

The accurate detection of dangerous security vulnerabilities such as SQLI and XSS during code implementation phase of SDLC is still limited to the type of programming language. Static analysis for such vulnerabilities is most widely done in PHP. Some dynamic methods employ fuzzy techniques during testing or deployment phase. Unfortunately, both ...


2

I am not aware of any way to end a <script> without the presence of </script. (case insensitive, no encoding) If there is a syntax error anywhere in a particular script, then that whole script will not execute. (of course you seem to already know this, and thus you are trying to insert </script>) However, this is still serious because it is ...


2

Server side: As a security procedure they encoded the "/" in the "&#47" in order to avoid any directory path traversal or XSS (no luck mate). Try other methods of getting around the "/". Cheat-sheet: https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet Client side: Your browser is having a sort of XSS protection enabled. Try to disable that ...


2

I believe you're mixing up a few different threats and attack vectors here. Threat: MITM sniffing or setting tokens Location: Public wifi How to mitigate: Use HTTPS so the connection is secured over TLS/SSL. Also the cookie Secure Flag is recommended, and an HSTS policy with preload. Threat: XSS Location: Over the internet What it is: An attacker ...


2

There is a variant of XSS, sometimes called "Server-side cross-site scripting". It is much less common than client-side XSS. In fact, I have only seen it once on a live web site. It occurs when the server renders HTML documents. This can happen when the server produces a PDF (e.g. a printable invoice) and HTML is part of the chain. If the attacker can ...


2

You are mixing up scripts that run on the server, and scripts that run on the client. When you do XSS, you inject script on the client. Usually it is JavaScript, but it could be VBScript or some other client scripting language. You can not use document.write to write PHP. That function is JavaScript, and is therefor executed on the client. It writes in the ...


1

We need to consider exactly what a tight policy is. I have identified three levels: Level 1 - Stop XSS At this level, a tight policy will stop all XSS. If the site has XSS flaws, these will not be exploitable (assuming the user's browser supports CSP). An XSS attacker could still reference resources on their own server, which creates a web beacon. They ...


1

The problem isn't the WYSIWYG editor. They are clientside code. The problem with such editors is when they are integrated with the serverside to post content or perform an image upload. Much of the bad reputation comes from when they are included in a CMS plugin. Those integrate with the serverside code base and either aren't always coded securely or the ...


1

Text entities in HTML can't do anything interesting, and the content between span tags is interpreted as text. To do anything interesting, you'll need to inject a new entity (which is done using < and >), or you'll need your input to be injected into a non-text location (such as the parameters of an entity, or inside a <script> block, or similar)....


1

Lets imagine that there is admin-account in specially crafted webapp and that account has rights to get certain files from server (like, if admin requests /getfile.php?filename.txt, the getfile.php returns content of "filename.txt"). Then you could inject ajax-request to admin's client side and request files with that.


1

Well It's not about OWASP Top 10 / Top 20 / Top n, those can be changed over time (xss is more present right now then it was back in 90'), what actually matters at OWASP is there update to the technology methodologies (v.1 v.2 .. v.4) that offer an exhaustive testing plan of a Web based application. If you want to simplify them ... you should take in account ...


1

As already suggested a beef hook into the xss vector can be very dangerous in this case. Apart from the traditional metasploit intergration into the beef hook, there are some other scenarios which needs to be kept in mind. WebRTC javascript API including MediaStream,RTCPeerConnection, RTCDataChannel enables direct communication between browsers using TURN ...


1

Old versions of IE will treat it , if you embeded it in a script tag it will be rendered and executed



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