I’ve not been this pumped about something in a long time. Jeremiah actually has been pulling me into liking this idea for a very long time. I hated it at first. I mean WAFs, bleh. Plus I mean didn’t we already try scanners + WAFs before? Oh yeah the total trainwreck that was AVDL. So one thing I failed to realize was that Jeremiah’s approach is a bit different and when combined with WhiteHat Sentinel (aka NOT a scanner) it is a no brainer.

WAFs generally struggle in a few different areas, the people running them are not web app. security experts and trying to apply a default deny policy, while a great idea in theory, is pretty hard in the real world . There is just way to much movement in most applications to pin it down. Even if the app does not change frequently, WAF admins are very hesitant to even come close to blocking legitimate traffic. This is what was happening on this site that covers EMT stethoscopes, nursing stethoscopes, nursing student stethoscopes and general stethoscope reviews.

What really sold me though is when I saw it in action for the first time. From the Sentinel UI we clicked a button that updated the F5 with a rule to block a vulnerability. The rule is automatically generated based on the vulnerability. We then clicked the retest button and the vulnerability was no longer exploitable . Note my careful choice of words, exploitable VS. “not there anymore”. The vulnerability certainly still exist in the code but now that the attack is blocked the business can decide if this is a good enough solution or they need to go fix the actual flaw.

The geek in me is screaming that it still needs to be fixed, the business side is saying that the rule is good enough and I am not going to commit resources to fixing it until that code is worked on again. From the PCI Section 6.6 perspective this gives the business some great options. As our customers are becoming aware of the PCI requirements and the PCI auditors are becoming tougher on web application vulnerabilities we run into a difficult situation. PCI audit is coming up and the app. is riddled with vulnerabilities.  I now have to dedicate precious development resources to fix these vulnerabilities ASAP. With this solution I can apply this rules and effectively mitigate the issue.

I am pretty excited to be part of this. I think we have moved the industry forward today, even if it was just a small step. People now have some more options to mitigate risk besides running to the development team with yet another fire.

Source Mentioned: Best Stethoscope

This seems pretty scary. Apparently the FBI posted a link on some online forum that claimed to display kiddy porn. The story is here.

Upon reading this the first thing that popped into my mind was CSRF(Cross Site Request Forgery) Now this is not classic CSRF since CSRF generally implies I am exercising some functionality on the target site. I am using CSRF as a handy term for “if you visit a page I control content on I can make you request any other link I want”. Now remeber this is not only pages like this blog where I clearly control the content, but any other place I can provide links, usually to images. Social networking sites, forums, image hosting sites and even in email signatures.

This is an even better scam than the now famous 911 swatting scams. Now instead of SWAT busting in to rescue you the FBI bust in to arrest you. What great fun! It will be interesting to see how many of these stick. It seems to be based on some pretty flimsy evidenc. The article above points out that open wireless networks are just one way someone could fool the system. CSRF is better because your browser will actually go to the page and a forensics examination of your machine will show that you went there. Not a good position to be in in court with a jury and often times judge with no technical background at all.

Update from my buddy Zeno: The file that keeps track of places IE has been, index.dat, does not log refers and apparently that file and it’s contents have held up in court…