New answers tagged

0

You may want to take a look at the "Making CSP Great Again" presentation from AppSec Europe, which discusses some nuances of deploying effective CSPs. The comment by user grc mentioning Sub Resource Integrity is another way to help ensure that only scripts you have explicitly whitelisted (based on the hash contents) can be loaded. This means that you can ...


0

If you really want to secure the javascript used on your site, just copy on your own server the jQuery part that you use and serve it directly from there. CDN are extremely useful for large contents like video file. But javascript is not that heavy and can normally be cached by client browsers, so they load it only once for a whole session.


0

my understanding is its not possible to specify individual JS files. instead the principle is you trust the CDN provider in this case you trust google. I think it would be a nice extension to the CSP if you are allowed whitelist the domain and JS resource.


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


0

In this case the XSS is actually independent of the server side, which means you can actually ignore sending data to the API and instead focus on the UI. This means you could essentially write an XSS scanner that mocks the API, and then detect changes in the browser. You could use webdriver/selenium or similar to drive the browser. Another alternative could ...


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


0

You could definitely hijack the session by getting cookies, if you can execute the Javascript in that page/frame by sending the message. Refer : How to send cross domain post request via javascript The minimal requirement here is, you'll need a server which you control. So that you can configure the Access-Control-Allow-Origin header of the response ...


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.


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


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


0

I'm going to have to concur with SilverlightFox's assessment that successful exploitation of this "possible" attack vector will be severely hindered (as is the intent of encoding in the first place). There doesn't appear to be any way to "consume" (i.e. overwrite) characters under UTF-8, and the characters you need to break out of are already being escaped. ...


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


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


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


1

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


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


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


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


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


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


0

As this feels as a school-assignment, I would recommend buying one or two of the "basic" web security books which often discusses all of the most popular vulnerabilities. This will make you understand the vulnerabilities better and therefore you can explain them in any way you feel like in the paper. As for the interview part the google form idea ...


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


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


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


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


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


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


0

I'm assuming that you really can't dynamically change the text box - but I would strongly suggest that you re-examine that fact as it does seem to be the easiest and safest way to get what you want. You can't encode the output. There is just no way to encode < as something else without it being more character. That means that you would need to apply ...


0

You can use Chrome's Inspector to view the DOM tree as HTML. There you see the rendered result of the AngularJS processing. But provided that you use AngularJS correctly, it takes care of all escaping and won't allow any XSS vulnerabilities (otherwise they are vulnerabilities in AngularJS itself). You need to use $sce and ng-bind-html to make AngularJS ...


-1

<img src=x onerror=confirm(String.fromCharCode(88,83,83))> If the site use SVG as images you can use this one: <svg onload=prompt(1)> No <script>, alert, msgbox, and or prompt word needed.


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


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


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

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


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


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


2

The risk isn't that a script such as http://attacker.com/omg.php runs on your domain, it is that a user manages to break out of the <div style='background-image: url("http://example.com/image.jpg")'></div> context where the URL is written to the page. Note the code has been corrected from your question (single quotes used for HTML attribute ...



Top 50 recent answers are included