Throwback Tuesday Developing Pedagogical Visualizations of Dense Matrix Operations on Interconnection-network SIMD Computers
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.
Tuesday, March 1, 2016
Don't Write your own XSS Filter
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.
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.
HTTP Login Pages with HTTPS Posts
A while back Troy Hunt talked about HTTP Login forms that post to HTTPS. The long story short is these are still unsecure. As a web developer, don't be fooled into thinking that just because you're POSTing to HTTPS that your customers are safe. No, you need to have an HTTPS login form/page or you're at risk. The HTTPS POST may prevent sniffing because the traffic is encrypted, but with an unsecure HTTP form posting to HTTPS you are still at risk for man-in-the-middle. With a man-in-the-middle the form action url could tampered with and changed so your credentials get posted to some attacker website instead of the real one.
Now finally FireFox will make this even clearer by warning users if they're logging in with on a website with this insecure configuration.
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.
Now finally FireFox will make this even clearer by warning users if they're logging in with on a website with this insecure configuration.
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.
EMET Blog
DFIR wrote a good simple to read blog about EMET, Microsoft's tool that blocks things like Buffer Overflow in userland.
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.
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.
Insecure Direct Object Reference 101
As a web developer have you ever gone through a Code Review or used the OWASP Top 10 and gotten to the "Insecure Indirect Object Reference" and wondered, what does that mean?
Well, Adam Logue recently posted a blog about a real world example of Insecure Direct Object Reference going bad.
The blog talks about a vulnerability they discovered on TGI friday's mobile website. There was an HTTP GET request getting sent to the TGI Friday server that passed a parameter (in bold below) called 'acctid'.
GET /alchemy-master/ws/TgifAccountActivity.asmx/AccountActivity?stoken=8970853507518770&acctid=123213123
This 'acctid' was an account id of the user and could be used to redeem for free food at the restaurant. Thus all an attacker had to do was replace their account id with some other user's account id, and then instead of redeeming their own points, they would be redeeming somebody else's points. Thus FREE FOOD! And this is a great example of an Insecure Direct Object Reference. Poor programming.
Here are 2 ways this could've been prevented if you were the web developer writing the code.
a.) Check access. Before committing those changes to the database, confirm ... does the account id match the user logged in? If no, deny.
b.) Use indirect object references. In this example, let's say the user logged in has 3 gift card account numbers (1=43554345, 2=344234, 3=4444422). Instead of passing the actual account numbers as query string parameters (43554345, 344234, 4444422) pass indirect/mapped references such as the numbers 1,2,or 3 ... and then when you get to the database unmap and determine that gift card 1=43554345 , 2=344234, and 3=4444422. This way the attacker could only inject the numbers 1,2, or 3 which all belong to this user, and thus the attacker could not inject an account number of another user.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Well, Adam Logue recently posted a blog about a real world example of Insecure Direct Object Reference going bad.
The blog talks about a vulnerability they discovered on TGI friday's mobile website. There was an HTTP GET request getting sent to the TGI Friday server that passed a parameter (in bold below) called 'acctid'.
GET /alchemy-master/ws/TgifAccountActivity.asmx/AccountActivity?stoken=8970853507518770&acctid=123213123
This 'acctid' was an account id of the user and could be used to redeem for free food at the restaurant. Thus all an attacker had to do was replace their account id with some other user's account id, and then instead of redeeming their own points, they would be redeeming somebody else's points. Thus FREE FOOD! And this is a great example of an Insecure Direct Object Reference. Poor programming.
Here are 2 ways this could've been prevented if you were the web developer writing the code.
a.) Check access. Before committing those changes to the database, confirm ... does the account id match the user logged in? If no, deny.
b.) Use indirect object references. In this example, let's say the user logged in has 3 gift card account numbers (1=43554345, 2=344234, 3=4444422). Instead of passing the actual account numbers as query string parameters (43554345, 344234, 4444422) pass indirect/mapped references such as the numbers 1,2,or 3 ... and then when you get to the database unmap and determine that gift card 1=43554345 , 2=344234, and 3=4444422. This way the attacker could only inject the numbers 1,2, or 3 which all belong to this user, and thus the attacker could not inject an account number of another user.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
ModSecurity Virtual Patching 101
There is a great article by High-Tech Bridge Security Research team about the Open Source WAF ModSecurity. I thought it'd be interesting to cover a few of the topics they mentioned at a high level.
Have you ever had a scenario where a security vulnerability was identified (perhaps by a scanner, or an outside resources, etc.) but you were unable to immediately patch it. Perhaps you were in the middle of a large project and had no resources. Perhaps the vulnerability was in a fragile high risk area of the sites and numerous hours or days of testing are required. Perhaps the site is hosted/built by a 3rd party and you have to deal with formalities and other delays. A possible solution to any of these problems would be to apply a temporary "virtual patch" with your WAF in order to block the attack from occurring until you get the developers to build & test the real patch. Remember you still want to perform real patching, your virtual patching should only be temporary because WAFs are just another layer, and that layer could also have vulnerabilities or weaknesses of their own (such as WAF bypasses). Thus the only real way to prevent exploit is to perform a full patch.
But for the temporary fix, you might be wondering ... what does a virtual patch look like? Well essentially you can write a rule (think of it as similar to a SNORT IDS/IPS rule) that restricts what data can be utilized on the website to hopefully allow the good data and block that attackers data.
XSS Example
Exploit Url: http://www.mysite.com/product.aspx?productid=alert(document.cookie)
Virtual Patch:
SecRule REQUEST_FILENAME "/product.aspx" "phase:2, t:none, t:normalisePath, t:lowercase, t:urlDecodeUni, chain, deny, log, id:1001"
SecRule ARGS_GET:productid "!^[0-9]+$" "t:none"
To explain further, let's say in the example above that you confirm the productid parameter on the product.aspx page is vulnerable to XSS but you cannot apply permanent patch yet. Thus you want to create a temporary WAF virtual patch to block attackers from exploiting it. The 'SecRule' keyword allows you to analyze and act upon variables. You'll notice there are 2 lines thus we are analyzing 2 variables. The 1st is the 'REQUEST_FILENAME' variable and it holds the name of the file being requested. In this case we validate that it's the product.aspx page. Then we can set a bunch of actions. The first one I want to point out is the word 'chain'. This indicates that there are multiple 'SecRule's that are getting chained together (in this case our 2 lines/2 variables we're comparing). Also it says 'deny' and 'log' which means if these chained rules match we are denying and logging it. Just like a snort rule there is an "id" also for tracking. There are also a bunch that start with the letter 't' which stand for transformation functions. 'none' starts you with a clean slate, then it's saying do all the comparisons in 'lowercase', and use the 'normalisePath' to eliminate any double slashes, and use unicode with 'urlDecodeUni'. The other action in the first line is 'phase:2' which indicates for the WAF to look at the Request. Phase 1 is the request headers, Phase 2 is the request, Phase 3 is the Response headers, phase 4 is the Response, and Phase 5 is logging. The phase is for performance.
The second line is another 'SecRule' on a variable called 'ARGS_GET'. More specifically, it's comparing the value of the 'productid' query string argument. This line creates a whitelist to basically attempt to allow the good data and block the attackers bad data. In this case it's providing a regular express that says the productid can only contain numbers (1 to many). Thus by allowing only numbers, the WAF will 'deny' the request and 'log' if anybody tries to pass anything other than numbers into the productid parameter. Just like that you've prevented the XSS.
SQLi Example
Exploit Url: http://www.mysite.com/search.aspx?keyword=value';insert+into+user+('admin','password');--
Virtual Patch:
SecRule REQUEST_FILENAME "/search.aspx" "phase:2, t:none, t:normalisePath, t:lowercase, t:urlDecodeUni, chain, deny, log, id:1002"
SecRule ARGS:keyword "'" "t:none, t:urlDecodeUni"
Just to provide a second example, above is a url that you've identified as having a keyword parameter vulnerable to SQL injection. In the case above, the attacker terminates the keyword value in SQL with the apostrophe, then inserts an admin user into the user table, then comments out the rest of the SQL. To prevent this we chain 2 'SecRule's again. We first check that we're on the vulnerable 'search.aspx' page and we're going to 'deny' and 'log' again.
The second line then look for the 'keyword' query string parameter, and if it contains an apostrophe or any unicode variation, then it will 'deny' the requst, thus you've temporarily prevented the SQL injection.
The article has many more great examples of how to block things like CSRF, Path Traversal, etc.
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.
Have you ever had a scenario where a security vulnerability was identified (perhaps by a scanner, or an outside resources, etc.) but you were unable to immediately patch it. Perhaps you were in the middle of a large project and had no resources. Perhaps the vulnerability was in a fragile high risk area of the sites and numerous hours or days of testing are required. Perhaps the site is hosted/built by a 3rd party and you have to deal with formalities and other delays. A possible solution to any of these problems would be to apply a temporary "virtual patch" with your WAF in order to block the attack from occurring until you get the developers to build & test the real patch. Remember you still want to perform real patching, your virtual patching should only be temporary because WAFs are just another layer, and that layer could also have vulnerabilities or weaknesses of their own (such as WAF bypasses). Thus the only real way to prevent exploit is to perform a full patch.
But for the temporary fix, you might be wondering ... what does a virtual patch look like? Well essentially you can write a rule (think of it as similar to a SNORT IDS/IPS rule) that restricts what data can be utilized on the website to hopefully allow the good data and block that attackers data.
XSS Example
Exploit Url: http://www.mysite.com/product.aspx?productid=alert(document.cookie)
Virtual Patch:
SecRule REQUEST_FILENAME "/product.aspx" "phase:2, t:none, t:normalisePath, t:lowercase, t:urlDecodeUni, chain, deny, log, id:1001"
SecRule ARGS_GET:productid "!^[0-9]+$" "t:none"
To explain further, let's say in the example above that you confirm the productid parameter on the product.aspx page is vulnerable to XSS but you cannot apply permanent patch yet. Thus you want to create a temporary WAF virtual patch to block attackers from exploiting it. The 'SecRule' keyword allows you to analyze and act upon variables. You'll notice there are 2 lines thus we are analyzing 2 variables. The 1st is the 'REQUEST_FILENAME' variable and it holds the name of the file being requested. In this case we validate that it's the product.aspx page. Then we can set a bunch of actions. The first one I want to point out is the word 'chain'. This indicates that there are multiple 'SecRule's that are getting chained together (in this case our 2 lines/2 variables we're comparing). Also it says 'deny' and 'log' which means if these chained rules match we are denying and logging it. Just like a snort rule there is an "id" also for tracking. There are also a bunch that start with the letter 't' which stand for transformation functions. 'none' starts you with a clean slate, then it's saying do all the comparisons in 'lowercase', and use the 'normalisePath' to eliminate any double slashes, and use unicode with 'urlDecodeUni'. The other action in the first line is 'phase:2' which indicates for the WAF to look at the Request. Phase 1 is the request headers, Phase 2 is the request, Phase 3 is the Response headers, phase 4 is the Response, and Phase 5 is logging. The phase is for performance.
The second line is another 'SecRule' on a variable called 'ARGS_GET'. More specifically, it's comparing the value of the 'productid' query string argument. This line creates a whitelist to basically attempt to allow the good data and block the attackers bad data. In this case it's providing a regular express that says the productid can only contain numbers (1 to many). Thus by allowing only numbers, the WAF will 'deny' the request and 'log' if anybody tries to pass anything other than numbers into the productid parameter. Just like that you've prevented the XSS.
SQLi Example
Exploit Url: http://www.mysite.com/search.aspx?keyword=value';insert+into+user+('admin','password');--
Virtual Patch:
SecRule REQUEST_FILENAME "/search.aspx" "phase:2, t:none, t:normalisePath, t:lowercase, t:urlDecodeUni, chain, deny, log, id:1002"
SecRule ARGS:keyword "'" "t:none, t:urlDecodeUni"
Just to provide a second example, above is a url that you've identified as having a keyword parameter vulnerable to SQL injection. In the case above, the attacker terminates the keyword value in SQL with the apostrophe, then inserts an admin user into the user table, then comments out the rest of the SQL. To prevent this we chain 2 'SecRule's again. We first check that we're on the vulnerable 'search.aspx' page and we're going to 'deny' and 'log' again.
The second line then look for the 'keyword' query string parameter, and if it contains an apostrophe or any unicode variation, then it will 'deny' the requst, thus you've temporarily prevented the SQL injection.
The article has many more great examples of how to block things like CSRF, Path Traversal, etc.
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.
Get-Hotfix Powershell
I thought this Powershell command was simple but useful.
$> Get-Hotfix KB958488
It will lookup a Hotfix on the current computer/server you're on and tell you whether it's installed or not, and if so on what date and by whom. If you leave off the KB # it'll just list out all hotfixes already installed. Pretty helpful! Here's more info at Technet.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
$> Get-Hotfix KB958488
It will lookup a Hotfix on the current computer/server you're on and tell you whether it's installed or not, and if so on what date and by whom. If you leave off the KB # it'll just list out all hotfixes already installed. Pretty helpful! Here's more info at Technet.
More about neonprimetime
Top Blogs of all-time
Top Github Contributions
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
Subscribe to:
Posts (Atom)