Security Musings Blog
A recent endeavor at Stanford University’s Security Lab found more sobering information on the reach and capability currently employed by trackers such as Epic Marketplace (formerly known as Traffic Marketplace). The lab found that the scripts used on affected sites were very fast and loaded thousands of links in invisible iframes so few users would ever notice them. Whenever the browser window closed, the scripts sent off their findings and also stored their progress in scanning links with a cookie. In order to avoid having parallel scripts run concurrently and slowing down the process, some even used some semaphore-like cookies to start and stop. By scanning thousands of hidden links, these scripts could quickly develop a comprehensive history of browsing, and the lab found that these links ranged from eBay listings to health clinics, a serious privacy concern.
If you’re new to the world of testing web application security, you may not be aware of the many great Firefox add-ons available that greatly help such endeavors. While others have compiled similar lists in the past, I thought this week would be a good time for me to share a few of the favorite tools I use in my own web app work.
- HttpFox: I’ve blogged about this one in the past; it lists for you every HTTP request made during a given browser session, with details on headers, cookies, parameters, responses, and more. Very handy to monitor traffic when you’re browsing around an app.
- HackBar: Another one I’ve mentioned before, the HackBar is a swiss-army knife that gives you some space for notes, common commands (such as base64 encoding or MD5 hashes), and perhaps best of all, an easy way to execute manual POST requests.
- FireBug: Perhaps one of the best-known Firefox plug-ins, FireBug is a powerful tool for inspecting a page’s DOM, debugging scripts, and investigating script variables.
- Cookies Manager+: As you can guess, this add-on lets you view and edit browser cookies to your heart’s content. Useful in tracking and spoofing session information.
- Modify Headers: Many web apps use special headers in various ways; this tool lets you set such headers manually when making requests. Spoofing XMLHttpRequest commands is one use case.
- User Agent Switcher: I’ve seen apps with vulnerabilities that only affected mobile versions of the site. This extension lets you imitate just about any browser, allowing you to test different site interfaces.
This list is by no means exhaustive and is geared towards manual testing, but it certainly provides a solid line-up for anyone looking to experiment with web app security. It also shows how easy it can be to get started tinkering with web apps. While I use Chrome for my everyday browsing, I use my tricked-out Firefox setup when I want to dig deeper. If you’re starting out, try using these add-ons against an educational app, such as WebGoat, Gruyere, or DVWA.
I hesitate to say that visio is only useful in pen-testing, because it can also be useful in developing a secure architecture, or a web page, and really just putting all the moving parts onto your screen (or paper) so that you can look at the big picture.
I use Visio to diagram networks and web pages that I’m looking at. The network diagramming is pretty obvious – a lot of people use Visio for network diagrams anyway.
Where the value comes for security folks is in the details you’re willing to add to the diagram – what ports are open on the firewall and what servers do they go to?
Another use for Visio is mapping out web pages. You can map out all of the POST and GET variables and cookies that are submitted for each page.
Again, the more detail you’re willing to put into the diagram, the more useful it will be.
So, what’s wrong with just drawing it out? I mean Visio takes a while to draw even fairly simple diagrams. Most people’s handwriting/drawing skills leave a lot to be desired (unless you trained as an engineer or architect), and many times, you’re working with a group of people and need to share the information. Chicken scratch doesn’t help get the needed information across.
That probably sounds like an awful lot, but in truth it isn’t. It’s awfully difficult to find exact figures on regulatory fines – companies tend to be rather tight-lipped on the subject, after all. But on the scale of companies and business fines, and knowing that companies in general, and hospitals in particular, are generally good at cushioning themselves against such damage, it’s just not that much.
Also, HIPAA is considered something of a paper tiger. Although HIPAA was passed in 1996, there weren’t any fines issued until 2006. While there have been quite a few fines and even criminal prosecutions since then, and the UCLA fine is the third “large” fine in 2011 – the largest being $4.3 million – that’s still not all that much on a business scale.
However, HIPAA compliance is a major concern for healthcare providers; a concern which is far out of proportion to the expected costs of non-compliance?
Why? Are all hospitals, insurance providers, and private practices that concerned with patient privacy?
I’d like to say yes. But, cynically, my time working at a hospital tells me the real reason: they don’t want to undergo an inspection.
HIPAA originally set the maximum fine for each individual violation at a mere $100, with the maximum possible fines being $25,000. Those limits were raised in 2008, and there is a risk of criminal penalties to boot, but that’s not the biggest risk, nor the biggest potential cost.
Each reported violation can trigger a HIPAA inspection. Inspectors can look over the entire facility, from top to bottom, looking for each and every violation. The costs involved in such an inspection, in terms of disruption to the facility, far exceed the possible fine involved.
The numbers don’t tell the whole story with HIPAA. The fear of an inspection has motivated hospitals throughout the nation to adopt far more secure practices with respect to medical records. While there can, and will be, data leaks, HIPAA is more effective than it seems.