There was a recent blog by Sjoerd Langkemper that walked through bypassing XSS Filters. It's a great example of why as a web developer you should NOT write your own XSS filter, but instead you a trusted and vetted security library written and reviewed by the pros. By Custom XSS (or SQLi) filter, I mean you should not try to write your own regular expression, pattern matching, character blacklists, etc. It's just too complex and you're bought to miss something or make a mistake. You need to use a library that everybody else has reviewed and is known to be correctly written and secure.
In the blog he provides great example. There was a regex written to remove this malicious code
(javascript\s*:)
And it would work great if the attacker followed the traditional pattern and entered malicious code like this
<a href="javascript:alert('test')">link</a>
But what if the attacker varied a little bit and URL encoded the letter s?
<a href="javascript:alert('xss')">link</a>
Uh-oh, your attacker just bypassed your XSS filter and your website is vulnerable to XSS.
Here's another example of a decent regex to blog javascript event attributes.
(ondblclick|onclick|onkeydown|onkeypress|onkeyup|onmousedown|onmousemove|onmouseout|onmouseover|onmouseup|onload|onunload|onerror)=[^<]*(?=\>)
But guess what, you missed one (or probably many). What about onmouseenter?
<div onmouseenter="alert('xss')">
Please trust me when I say, you can't do it yourself. I would never attempt it and you shouldn't either. Use a trusted library that covers all these scenarios and has thought of all the things that you have forgotten.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Showing posts with label XSS Filter. Show all posts
Showing posts with label XSS Filter. Show all posts
Tuesday, March 1, 2016
Tuesday, January 12, 2016
XSS Flaws lead to Keylogging,Webcams, & more
I've enjoyed talking about XSS many times on this blog. Today is another one of those days! We're going to bring it hopefully full circle this time. First just as a heads up I'm working in my VM environment with networking configured like this to have a Kali linux box with Apache Web Server and also with BeEF and a windows 7 box with chrome.
Let's say a developer wrote a vulnerable PHP user page on his goodsite.com with this line of code. It's vulnerable to XSS because it's just echoing the user-controlled input back to the screen. This can be really bad as we'll see in a minute.
echo sprintf("User: %s", $_GET['userid']);
Now an evil attacker may swoop in, discover this flaw, and try to get one of your users of the website to click on a link that looks like this
Notice the javascript that tries to load a hook.js file from an evil site. We'll get to what that is later. First you should know that by default Chrome and many modern browsers actually would've saved your life already. Chrome's XSS auditor would've caught this and silently blocked it. You can see this if you view source and find the red highlighted text.
But let's say I was running an older insecure browser, the vulnerability was actually somewhere else and Chrome didn't catch it, or I'm evil and know how to evade the XSS Auditor, or I simply disabled the xss auditor feature (don't do this) in chrome like below.
Then truly bad things will happen as you see below. The evil attacker got my end user to go to my goodsite, but per the Chromes developer tab (F12) I'm able to see that even though my good page loaded, in the background, something else more evil loaded. A hook.js file from evilsite.com which came from the XSS injection of the script src tag. In addition, notice that the hook.js isn't done yet. It's actually created persistence. It's now running over and over every few seconds. This looks bad.
Over on the BeEF console the attacker probably sees some log like this showing him that you've joined his party
And at his disposal he can do whatever he wants as long as your browser and plugin versions support it including evil stuff like enabling your webcam
Or if you happen to type in a password or credit card
He's going to see that as well
One thing I found really cool about BeEF is that you can view all the javascript code behind the scenes making these hooks, keylogging, etc. work is all write there for you to view.
So if you're like me and have a background in web development as a good guy, then you can figure out exactly what code some of the bad guys are taking advantage of.
And finally I'll harp on it again, if you're a web developer, hopefully this blog post gives you another good reason to take XSS flaws seriously for the sake of your end user.
More about neonprimetime
Top Blogs of all-time
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Let's say a developer wrote a vulnerable PHP user page on his goodsite.com with this line of code. It's vulnerable to XSS because it's just echoing the user-controlled input back to the screen. This can be really bad as we'll see in a minute.
echo sprintf("User: %s", $_GET['userid']);
Now an evil attacker may swoop in, discover this flaw, and try to get one of your users of the website to click on a link that looks like this
Notice the javascript that tries to load a hook.js file from an evil site. We'll get to what that is later. First you should know that by default Chrome and many modern browsers actually would've saved your life already. Chrome's XSS auditor would've caught this and silently blocked it. You can see this if you view source and find the red highlighted text.
But let's say I was running an older insecure browser, the vulnerability was actually somewhere else and Chrome didn't catch it, or I'm evil and know how to evade the XSS Auditor, or I simply disabled the xss auditor feature (don't do this) in chrome like below.
Then truly bad things will happen as you see below. The evil attacker got my end user to go to my goodsite, but per the Chromes developer tab (F12) I'm able to see that even though my good page loaded, in the background, something else more evil loaded. A hook.js file from evilsite.com which came from the XSS injection of the script src tag. In addition, notice that the hook.js isn't done yet. It's actually created persistence. It's now running over and over every few seconds. This looks bad.
Over on the BeEF console the attacker probably sees some log like this showing him that you've joined his party
And at his disposal he can do whatever he wants as long as your browser and plugin versions support it including evil stuff like enabling your webcam
Or if you happen to type in a password or credit card
He's going to see that as well
One thing I found really cool about BeEF is that you can view all the javascript code behind the scenes making these hooks, keylogging, etc. work is all write there for you to view.
So if you're like me and have a background in web development as a good guy, then you can figure out exactly what code some of the bad guys are taking advantage of.
And finally I'll harp on it again, if you're a web developer, hopefully this blog post gives you another good reason to take XSS flaws seriously for the sake of your end user.
More about neonprimetime
Top Blogs of all-time
- pagerank botnet sql injection walk-thru
- php injection ali.txt walk-thru
- php injection exfil walk-thru
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)