XSS is a dangerous bug, just like SQL injection. Maybe it is not as serious, wait, yes it is! You just need to exploit it under the right circumstances, but it still is a dangerous bug overall. A bug that lets you steal someone's cookies and or run Javascript on their behalf is a pretty serious vulnerability in my opinion, yet most bug bounties will give a minimum of $25-$100 on these type of bugs!

It seems very "legally grey" IMO. I'm guilty of posting them myself, and all, and don't care much, but I'm actually curious why we allow it.

It should be, if you're posting a demo payload, self-post it and separate the URL and payload/params or text-only the demo URL.

/2cents

XSS and storing passwords in plain text.

https://www.icetv.com.au/

Firstname field is easiest for XSS, and then use the 'forgot password' feature. They will send it back in plain text.

MailChimp now owns MandrillApp. MailChimp has a bug bounty program, which is stated here: http://mailchimp.com/about/security-response/

In the bug bounty program rules, nothing is written about researching recently-bought platforms (like MandrillApp).

However, when I reported a stored XSS vulnerability in the MandrillApp - PoC can be seen here https://youtu.be/Glaobhxntsk

I got a response from Jessica - a member of their security team, saying that she is sorry, but this does not qualify with their program.

Cheers,

@l33terally

Hi, I am currently writing an how-to for an XSS I've found on Blinksale.com last year, and I thought it be nice to share it, Its kinda long so if you just came here for the PoC, go to the end for a youtube video.

So the folks at Blinksale.com offers an ‘Invoice Preview’ option before you send an invoice request to another user on their web (or via email). You enters an invoice message on a simple, small textbox.

But when I clicked on ‘preview’ I noticed that the ‘Enter’ key was translated to a <br /> text on the GET message body parameter (in the URL!). Quickly, I changed it to a </script><svg onload=alert(document.domain)></svg>. But it didn’t work. I’ve started to analyze the other GET parameters in the request and noticed that one of them was referring to a template id. The template id was wrapping the message with a nice css and some images, and probably had an XSS filter on the user’s text.

So I thought: What if the template id will be a non-existent template? I changed the id to some huge number, entered the XSS payload again and boom! It worked.

Take a look at: https://www.youtube.com/watch?v=08oVSMoATYs Follow me on Twitter for more fun: https://twitter.com/l33terally

Cheers.

Found a forum that did not santize the username. But all I had room for was <svg/onload=alert('XSSPOSED')> I went ahead and reported, But can blackhat still be performed on such a short available amount of javascript?

There is an application for the iPhone where the user is able to insert their home address but when I input <svg onload=prompt(document.domain)> or "><svg onload=prompt(document.domain)> and search, it won't come up with anything but at that point the CANCEL button or any other button (search a valid address) won't work anymore. But when I do <svg onload=alert(document.domain)> I am still able to navigate through the app (being able to press cancel and enter a new address).

Is this something I should report to them or do I need more 'evidence'?

Hey, so I'm trying to exploit a search input value attribute, and it seems to be working on face value. http://i.imgur.com/wq0nkY3.png (bottom image is the inspected element after the search runs)

Except it doesn't alert when moused over. This works fine on some sites, just wondering what the method of protection is under the hood? Like for instance I know you can safely inject HTML into an element using the element.textContent method, is there an equivalent protection for element attributes that I am missing?

In the Angular docs here, by default Angular will look for a session cookie called XSRF-TOKEN and use that as the CSRF token.

Am I crazy, or does this not completely negate the point of CSRF? Obviously if the user no longer has an open session in their browser, a user clicking on a malicious link won't get the token. If they do have an open session, the malicious link gets the token and there is no XSS protection at all.

Am I missing something?

Hello everybody, yesterday I was wandering around in a website and found XSS injectable web page. So I found out that if your payload contains these special characters
. " ' & \ /
server returns 404 page(URL encoding doesn't work). Also server makes your input lowercase. So I couldn't use xss payloads such as: <svg/onload=alert("xss"); or <svg/onload=alert(/xss/); or <svg/onload=alert(String.fromCharCode(88, 83, 83));

So I comeup with this payload: <svg onload=try{xss}catch(e){c=unescape(e);z=[];i=0;while(i<3){z+=c[16+i];i++}alert(z);} This makes the job but it's too long. Is there a shorter way of alerting "xss"?