Blog :: by Wade Woolwine

New Research Papers Posted

I’ve posted a couple research papers that I’ve written recently.

Secure Authentication and Authorization
In this paper, I lay out the key components to planning, designing, and implementing a secure authentication and authorization model for web applications. I discuss topics like data classification, application functionality inventories, unique session ids, and login forms providing PHP code samples as examples.

Cross Site Request Forgeries (CSRF)
In this paper I describe CSRF vulnerabilities, how they occur, and different techniques that can be used to mitigate them. Some of the mitigating techniques discussed include nonce checking, server side business logic enforcement, CAPTCHA, and IP address based rate limiting.

Please take some time to check out the Research / Papers tab on the blog and feel free to leave some comments.

Posted in Code Security, Enterprise Security, Implementation Security, Research, Security Design, WebAppSec | No Comments »

Reader Opinion: Degrees and Colleges

Not really a security related post, but I’m interested in gathering some opinions about colleges and degrees. The reason being is that I’m becoming more and more interested in going back to college to get my bachelors (and maybe a masters).

I was in an interview some months back where the group of gentlemen interviewing me were really grilling me about not having a degree. This is not the first time, of course, but this one really struck home, because I had the chance to catch up with one of the gentlemen who informed me that if I’d had a degree, then I would have been a perfect fit for the job. WHAT?! This was particularly odd for me since I don’t feel like a lack of degree has hindered my career advancement, in fact I’m very happy with what I have accomplished thus far.

I understand the arguments from both sides, and can’t really say I disagree either way, but in a market where new players are jumping in every day, wouldn’t it be wise to have as much weight on your side when competing for jobs or contacts? My thought is YES.

So here’s where I’m soliciting your input (please leave a comment):

1. Do you feel that degrees are important for career advancement?
2. How do you feel about colleges like Strayer or UMUC that are not your typical 4 year institutions and cater largely to working professionals?
3. Are you or have you been in a position where you want to continue your education, but have a full time job and a family to contribute to? Can you share you experiences?

I thank you for sharing your opinion.

Posted in Research | 5 Comments »

Metrics to Support your WebAppSec Program

In business, you typically find that a critical question associated with investing in security is “How much will it cost if we don’t do X?”. It’s no secret that it’s still very difficult to justify a web application security program to those who approve the dollars. Sure, for breaches involving financial loss or financial information theft, justification for prevention can leverage the cost of the financial loss. But consider an XSS vulnerability in a webmail program or a CSRF vulnerability in the social network du jour. How do you determine the cost of an attacker SPAMMING your users or performing unauthorized changes to personal data in order to justify your program? You need to scare executives enough to care…any they only speak numbers.

Numbers can be obtained using existing sources of knowledge including findings from existing security mitigation, entries from web server access logs, and Web Application Firewall (WAF) deployments. There are several methods of extracting and consuming this data such as Abnormally Detection Systems (ADS), vendor provided data viewers, or custom scripts. Each organization will have different needs and available budget, so careful consideration must be taken when considering the various options for collecting and analyzing the data.

Metrics from Existing Security Mitigation
I am making the assumption that there is already some form of Quality Assurance (QA) for security taking place on the web applications your company produces. Even if your QA program is a single person with a knack for running some tools, the findings from these efforts can be tracked, labeled, and categorized. Over time, these data points can be leveraged to justify additional investments in staff, training, tools, or outreach efforts. The Common Vulnerabilities and Exposures (CVE) and National Vulnerability Database (NVD) have developed a common way of defining, tracking, and measuring vulnerabilities. The following are a few examples of the kinds of metrics which can be obtained from CVE/NVD style vulnerability tracking:

• Vulnerability risk scoring
  Providing a consistent rating for risk for vulnerabilities which is based on a repeatable scoring of business and technical vectors will provide a metric from which prioritization for mitigation can be derived. Additionally, integration of this score into vulnerability reporting will provide an easy way to to quickly communicate the importance of any given issue. CVE/NVD scoring.
• Vulnerability classification distribution
  The CVE/NVD methodology defines categories in which to classify vulnerabilities called the Common Weakness Enumeration (CWE). These categories include authentication issues, XSS, path traversal, and design errors amongst others. The metrics obtained from this data will provide justification for security development for the design and development teams.
• Vulnerability totals per project or development team
  Being able to track vulnerability totals across projects or development teams will provide additional leverage for targeted training for development staff. Imagine being able to walk into the Director’s office and justifying the cost of bringing in an expert to discuss secure authentication and authorization in web systems through hard numbers demonstrating the needs of the business.

Metrics from Web Server Logs
Web server logs contain a wealth of information relating to the sort of attacks taking place across your company’s web properties. The key to making use of this data is consistent monitoring and tracking of the chosen data points. Some key data elements worth tracking include:

• Source IP address
  The source IP address of the HTTP request can be matched against an DNSBL database or a private IP blacklist in order to track use of the application by known threat agents.
• HTTP methods
  RFC-2616 defines a finite number of HTTP methods allowed in the HTTP protocol. Any deviation from the defined standards could adversely impact misconfigured webserver and should be considered an offensive action.
• Requested URL combined with HTTP response status codes
  Being able to track the number of requests against URLs will help in determining the presence of rogue files on webservers and help identify scanning for common hidden directories. Using the HTTP response codes will help identify instances where the requested resource returned status codes other then the 200 and 300 series.
• Query string parameters
  Query string parameters are the most prevalent location for input based attacks. An easy way of identifying offensive name/value pairs is to use the regular expressions in the relevant mod_security rules (see mod_security rule file modsecurity_crs_40_generic_attacks.conf).
• Client browser strings
  The client browser string identifies the type of browser and it’s capabilities to the web server. This information can be instrumental in identifying automated attacks against your company’s web properties. There is a lot of knowledge which can be gained from tracking bad browser strings, but this certainly goes beyond the scope of this post.

Metrics from WAF
Similar to obtaining metrics from web server logs, metrics obtained from Web Application Firewalls (WAFs) can be used to identify attacks taking place against your company’s web applications. I personally recommend using mod_security as it’s free, flexible, and powerful. Initial deployments of mod_security should be in log only mode until it has been determined that the enabled rules are not prohibiting legitimate users from using the application and that the rules are enforcing the intended restrictions.

Of course, I understand that getting this information together might present somewhat of a challenge, but the data points obtained from this metricizing excercise will provide irrefutable hard data on existing security controls as well as areas for improvement. I’m currently going through this excercise, so over the next couple months, I’ll hopefully be able to provide some numbers to demonstrate the effectivness of my efforts.

Posted in Enterprise Security, Research, WebAppSec | No Comments »