21–30 of 47 posts
Earlier quoted context omitted.
Imagine a link like this: https://example.com/login?vulernable-param=evilcredentialste... If I can convince a user to click that, and then login, I can steal their username, password or anything else. Basically anything they do in that window after clicking that link can be compromised.
Yes, but that gets passed to the server.
"Single Page Apps increase the amount of client side logic and user input processing. This makes them more likely to be vulnerable to DOM-based XSS, which, as previously mentioned, is very difficult for website owners to detect." Hmmm...assuming your back end has all the requisite validation and other security in place, how can a SPA cause an XSS? Are there any purely client side attack vectors (XSS or otherwise) tha…
Yes, a very common dom-based XSS vector is against document.hash, which is never passed to the server. Versions of Adobe Robohelp keep getting pwned by this. The article is kind of wrong that attacks against the URL won't be detected by the server since a decent WAF will detect this.
Nope, nope, and nope. In a DOM based attack via a GET request, an attacker can place the payload after a hash (the pound, ergo anchor reference): http://foobar.whatever/foo?bar=tender# VECTOR> No browser sends either # or anything after it to the server, thus the only way to detect this attack is to have some active script in the DOM which sends the document.location to the server but of course if the attacker knows about that and if they can get to the DOM before that script, well, it's over.
Earlier quoted context omitted.
> OSS just gives you an option to "fix it yourself". I would also say that generally speaking you also get more eyes on your source code so you increase the likelihood that someone will find the flaw more quickly (although you could also say it's easier for bad actors to locate flaws to exploit too).
Well we are comparing apples and oranges here because this small open source repo most certainly have less people looking at it than Intel have engineers working on ME.
Also, a single company provides limitations - you've got blinders on, and your project isn't open for those with a different perspective to come in and take a look and notice something. I honestly think that fresh, open, and global perspective is truly key the success of OSS.
"Single Page Apps increase the amount of client side logic and user input processing. This makes them more likely to be vulnerable to DOM-based XSS, which, as previously mentioned, is very difficult for website owners to detect." Hmmm...assuming your back end has all the requisite validation and other security in place, how can a SPA cause an XSS? Are there any purely client side attack vectors (XSS or otherwise) tha…
Imagine a link like this: https://example.com/login?vulernable-param=evilcredentialste... If I can convince a user to click that, and then login, I can steal their username, password or anything else. Basically anything they do in that window after clicking that link can be compromised.
Earlier quoted context omitted.
Yes, a very common dom-based XSS vector is against document.hash, which is never passed to the server. Versions of Adobe Robohelp keep getting pwned by this. The article is kind of wrong that attacks against the URL won't be detected by the server since a decent WAF will detect this.
>a decent WAF will detect this. Nope, nope, and nope. In a DOM based attack via a GET request, an attacker can place the payload after a hash (the pound, ergo anchor reference): http://foobar.whatever/foo?bar=tender# VECTOR> No browser sends either # or anything after it to the server, thus the only way to detect this attack is to have some active script in the DOM which sends the document.location to the server but…
Earlier quoted context omitted.
Yes, a very common dom-based XSS vector is against document.hash, which is never passed to the server. Versions of Adobe Robohelp keep getting pwned by this. The article is kind of wrong that attacks against the URL won't be detected by the server since a decent WAF will detect this.
>a decent WAF will detect this. Nope, nope, and nope. In a DOM based attack via a GET request, an attacker can place the payload after a hash (the pound, ergo anchor reference): http://foobar.whatever/foo?bar=tender# VECTOR> No browser sends either # or anything after it to the server, thus the only way to detect this attack is to have some active script in the DOM which sends the document.location to the server but…
Earlier quoted context omitted.
OSS is no silver bullet - you still have to do your due diligence to have secure system. OSS just gives you an option to "fix it yourself". Just recently I was reading a library and stumbled upon this interesting crypto tidbit [0] ("XXX get some random bytes instead"). Maybe a paid engineer would've designed it better but history is full of counter-examples (see CVE-2017-5689 [1]). [0]: https://github.com/nitram509/m…
> OSS just gives you an option to "fix it yourself". I would also say that generally speaking you also get more eyes on your source code so you increase the likelihood that someone will find the flaw more quickly (although you could also say it's easier for bad actors to locate flaws to exploit too).
What I'd say is that given an equal amount of security effort an open source lib is more likely to have higher security, however by far and away the most important factor here is the amount of security effort employed and that is not generally correlated with the software being open source.
Earlier quoted context omitted.
Imagine a link like this: https://example.com/login?vulernable-param=evilcredentialste... If I can convince a user to click that, and then login, I can steal their username, password or anything else. Basically anything they do in that window after clicking that link can be compromised.
Wouldn't evilCredntialStealingJavascript() have to be stored on the server in the first place...?
Earlier quoted context omitted.
Imagine a link like this: https://example.com/login?vulernable-param=evilcredentialste... If I can convince a user to click that, and then login, I can steal their username, password or anything else. Basically anything they do in that window after clicking that link can be compromised.
Wouldn't evilCredntialStealingJavascript() have to be stored on the server in the first place...?
DOM-based XSS is when JavaScript running on the client takes data from a "source" (URL parameter, DOM content, cookie, LocalStorage, etc), manipulates it, and then executes it on a "sink" without properly escaping it. Examples of "sources" and "sinks"[1].
I've reported DOM-based XSS on a website that parses user-generated comments for URLs then converts the comment by adding hyperlink markup to the URL. It was done insecurely, so I managed to use combinations of spaces and other HTML attribute delimiters to inject an "onMouseOver" attribute and collect a bounty (about $2000 IIRC). In my case, the payout was large because the data was stored on the server (therefore it was persistent XSS), but with URL fragments, it's possible for the server to never see the content that is passed to the "source".
[1] https://docs.google.com/spreadsheets/d/1Mnuqkbs9L-s3QpQtUrOk...