While I think that Jeremiah Grossman is absolutely on to something with his theories of alignment of interests in Web Security, I would argue that attaining the goal would go against human nature. Since the dawn of time, human have been in competition with one another and the only thing that’s really changed is the prize for being “best”. In pre-historic times, it was food, fire, and a safe place to sleep. In the middle ages it was land, crops, and livestock. In modern economies, it’s all about the money. For those actively participating in society, money virtually defines who you are in society. Actors, sports professionals, and CEOs of fortune 500 companies rake in hundreds of thousands of dollars and their quality of life shows it with nice cars and lavish housing. While middle class and below are barely making ends meat and most are working very hard for every dollar they spend.
Things aren’t much different in the business world. Companies who perform well go public and have millions of investors, companies who perform poorly go out of business, and once again, the measure of success is money. The examples cited by Jeremiah (SSL for web traffic, data encryption, and getting rid of IFrames) just further illustrate my point. While these practices would do a great deal for protecting their customers, they cost money and affect the bottom line profits, and therefore are not implemented. Yes, I know that security incidents end up costing the company more money in damage control than it would have cost for the safeguards to be implemented in the first place. This is the line security professionals have been giving senior executives for years. Has it worked? It doesn’t seem like it: Ask any of the 60% of the top 100 most popular websites who’ve hosted malware in the first half of 2008. (Websense security Labs™ (State of internet security -Q1 – Q2, 2008)
At this moment, the greatest asset that has been given to security professionals are regulations. Whether they be industry (PCI-DSS, SOX, etc) or Government (FISMA, NIST standards, etc) these regulations on IT Security have proposed to fine/hold legally responsible companies who do not attempt to enforce a minimum level of safeguards to protect their customers. By no means am I saying that these standards are perfect, there is far too little enforcement, the rules are not always described clearly and there are many cases where auditors are coerced into giving a passing grade to infrastructures which do not meet the requirements. What I am saying is that the idea of fining companies for failing to protect consumer data is the right way to go when you’re dealing with executives who’s primary driver is making money for the company.
I propose the following to answer Jeremiah’s question “How do we get the owners of 187 million websites, 17 million developers, browser vendors, universities, governments, ISPs, compliance auditors, and security researchers all to pull in the same direction towards a more secure Web?”:
Establish more laws and industry regulations defining how companies should conduct themselves.
Admittedly, this is a double edged sword. More checkboxes != more security, but it does give the professionals in the field some solid backing when presenting security concerns to executives.
Academics and researchers must collaborate to change the education system.
Remember the old saying “work to make the world better for your children”? We have an army of little tech savvy kids coming through the education system. Lets teach them about information security and privacy issues so that as they move into consumerism, they will instinctively demand security from the products they consume.
Figure out a better way to demonstrate the value of IT Security services.
This seems to be the Achilles heel of the IT Security world. How do you demonstrate the value of preventative counter measures? Yes, I know, another question VS. an answer.
Offer better security solutions and products.
As stated in Jeremiah’s article, “Security vendors love strongly enforced compliance standards as it frees up budget for their solutions, which may not reduce risk, but have to be purchased to satisfy a checkbox”. We don’t need more checkbox solutions, we need tools that actually empower companies with the right information so that they can easily get a snap shot of the current security posture. White Hat Security has a great tool/service hybrid where vulnerability data collected during automated assessment is pre-vetted by WhiteHatSec security engineers before being presented to the customer. As a quick disclaimer, I don’t work for WhiteHatSec, but have had the opportunity to see their product in action.
Greater focus on outreach and communications.
As the final, and perhaps most important solution, I propose a greater focus on outreach and communication. Security is still a field where only those who have the history and passion for computers truely understand what’s going on. This needs to change. The average web consumer must be educated to understand the personal ramifications of the “laiser faire” attitude that plagues the web application security world.
Please feel free to share you thoughts in the comments, I’m very interested to hear what my peers have to say on this subject.
In order to effectively implement my plan for tracking enterprise vulnerability metrics and their associated data points, it was clear that a custom application for data entry and report viewing would be required. As such, I wrote a PHP/MySQL web application with the following features and functionality.
Data Model – In order to structure the collected data in the database in a manner which facilitates data extraction from reports, I had to define the reporting needs early in the development process. By doing so, I was able to create a relational data model which makes reporting fast, accurate, and reliable.
Data Input – I’ve provided a series of HTML forms which provide the user with all the data points from my previous article. These forms have been designed with a heavy focus on ease of use and rapid data entry. To provide these features, the input for the required data points have been grouped logically and implement a feature for quick input where the user can select from a list of recent entries for the given data points (eg: recent contacts, recent CVE numbers, etc).
Reporting – I’m a big fan of keeping reporting as open as possible: it makes life much easier down the road. As such, I created a reporting framework which is capable of outputting a list of vulnerabilities based on a query for any data point stored in the database. For example, if you want to know which reports are associated with a given manager, business unit, vulnerability class, or keyword just select your preferences on the search page, and view the results.
Statistics – A data collection tool is worthless unless you have a way to quickly determine the characteristics of the data stored in the database. As such, I created a statistics page which provides the viewer with a snapshot of the vulnerability metrics based on similar characteristics. The following details the statistics and their intended purpose:
Vulnerabilities Created and Resolved
Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period.
Vulnerabilities Created and Resolved per Category
Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per vulnerability category.
Vulnerabilities Created and Resolved per System Type
Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per system type.
Vulnerabilities Created and Resolved per Source
Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per vulnerability source.
Vulnerabilities Created and Resolved per Impact Rating
Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per impact rating category and value.
Vulnerabilities Created and Resolved per Risk, Severity, and Probability
Simple count of vulnerabilities created and resolved (seperate counts) in the system for the given time period per risk, severity, and probability rating.
Vulnerabilities Created and Resolved per Domain
Simple count of vulnerabilities created and resolved (seperate counts) in the system for the given time period per domain name.
Top Report Owners
Simple count of vulnerabilites created and resolved with average time to resolve in the given time period per report owner (the security engineer assigned to the vulnerability).
Top Business Units
Simple count of vulnerabilites created and resolved in the given time period per business unit listed in the contact field.
Top Managers
Simple count of vulnerabilities created and resolved in the given time period manager listed in the contact field.
The tool also contains several usability features such as mass actioning of vulnerabilities (eg: resolve multiple reports at once), a data authorization model defined by report owner (owner can edit and view, others can only view), and a “my” page which displays reports relevant to the user.
In the future I hope to seperate the parts of the tool which are specific to my environment and open source the project so that others can gain visibility into their vulnerability posture.
Some time back I posted about designing and implementing the processes and tools which would enable me to track vulnerabilities affecting the enterprise throughout their security life cycle (identification to mitigation validation). In addition to providing a central repository for all enterprise vulnerabilities, I also wanted to make sure that we could use the metrics derived from this data to support investments in other areas of IT Security. My target was to have everything ready to start tracking vulnerabilities on the first day of business in 2009.
The data points I decided to track were primarily aimed at providing visibility into how vulnerabilities were identified, who was responsible for them, establishing an enterprise risk profile, and categorizing vulnerabilities according to risk factors. The following is a more detailed list of the metrics I’m tracking and their intended purpose.
The Data Points
Report Source – Tracking where the vulnerability reports are originating from. As options, I decided on direct report, findings from automated scanning, and all relevant existing security processes (security assurance, incident response investigation, etc) as sources.
System Type – Tracking the type of system affected by the vulnerability. As options, web applications, desktop applications, hosts/networks/operating systems, and web platforms seem to encompass all major system types.
Vulnerability Class – Being able to abstract individual vulnerabilities into something that is digestible by a non-technical audience is critical in this field. The National Vulnerability Database (NVD) has adopted a cross section of the Common Weakness Enumeration (CWE) hierarchy that is broad enough for the diversity of vulnerabilities most enterprises would encounter. For more information, checkout the CWE page on the NVD website, http://nvd.nist.gov/cwe.cfm.
Impact Ratings - Giving us a smart way to answer the “how bad is it?” question. The NVD has developed a framework (Common Vulnerability Scoring System – CVSS) where the characteristics of the vulnerability are supplied and the high, medium, low ratings for risk, severity, and impact are derived mathematically based on the supplied characteristics. The mathematical formula for the computation is available in the CVSS documentation, but I had a different idea for computing the h/m/l ratings. First, here are a few of the characteristics, their ratings, and descriptions:
Access Vector (AV)
Local - vulnerability can only be exploited from the local system. LAN - vulnerability can only be exploited from the local area network. Network - vulnerability can be exploited from the internet.
Authentication (AU)
User - User level authentication is required to exploit the vulnerability. Admin/Root – Administrator/root level authentication is required to exploit the vulnerability. None - No authentication is required to exploit the vulnerability.
Remediation Level (R)
Official Fix – The vulnerability has been fully remidiated and tested according to guidance given by security staff. Temporary Fix – The vulnerability has been mitigated temporarily while a permanent solution is devised. Workaround – A workaround exists to circumvent the vulnerability. Unavailable – No remidiation is available for the vulnerability.
Not Defined – Remediation for the vulnerability is unknown.
Additional impact ratings include Access Complexity (AC), Confidentiality Impact (C), Integrity Impact (I), Availability Impact (A), Exploitability (E), and Report Confidence (RC). Each of the values associated with the impact ratings is assigned a whole integer from 1 – 3. For impact ratings where there are more then 3 options, I found that in each case, 2 of the options were close enough to be assigned the same value. For determining which value I would assign to each impact rating, I assumed the greater the value of the impact rating, the more serious the vulnerability for the given impact. For example, for Authentication, User is assigned a value of 2, Admin/Root a value of 1, and None a value of 3. I then weighted each impact rating based on the importance attributed to the impact. For example Access Vector (weight of 2) is much more of a factor when determning risk than Report Confidence (weight of 1). To further clarify the impact of a vulnerability, I wanted to produce ratings for risk, severity and probability which are determined with the following equations:
Risk: (2*(av) + 2*(ac) + 2*(au) + c + i + a + 2*(e) + 4*(r) + rc)/15. Severity: (c + i + a + 2*(e) + rc)/6. Probability: (2*(av) + 2*(ac) + 2*(au) + 4*(r))/10.
Once the risk, severity and probability have been determined, I use the following ranges to assign high, medium, and low:
High: >= 2.00. Medium: >= 1.00 and <= 1.99. Low: >= 0 and <= .99.
Contact Information – Tracking who is reporting the issues, and who is responsible for fixing them. For each contact entered into the system, I wanted to capture their name, contact information, business unit (only for enterprise contacts), and their manager (again, only for enterprise contacts). The purpose of the contact information data points is to be able to determine which group within the enterprise we can target for education regarding specific topics in security. For example if we find that product team X has an abnormally high number of input validation vulnerabilities, we could justify investing in some XSS and SQLi training and know that it will be beneficial.
URL – I wanted to be able to present the data by fully qualified domain name (FQDN) to easily present the data to site owners.
Other - In addition to the data points mentioned above, I’ve also provided inputs for tracking of CVE numbers and internal ticket tracking system numbers. While this isn’t particularly relevant to vulnerability tracking, it will give my management a tie in to existing processes.
Provided that the data entered into the vulnerability tracking system is reliable and up to date, answering the “What’s wrong?“, “How widespread?“, “Who’s responsible“, “What’s the exposure?“, “What if we don’t fix it?“, “Where should we invest resources?“, and “How’s the security?” questions should be no problem from here on out.
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.
As a web application security testing professional, you often encounter “snake oil” security implementations. A recent example would be the “Hacker Safe” ruse which has been exposedtime and time again by the security community. Today, I come to you with another: Partially encrypted web applications aren’t protecting you!! Let me explain the situation. Most web applications have implemented SSL/TLS encryption for you to login without exposing your username and password to the guy in the black trench coat also using the wifi at the coffee shop. This kind of protective measure inspires the trust of the user in the application, but does very little to actually protect your identity, data, or in the event of social applications, your reputation.
At the heart of the problem is the way that the web server maintains a unique session for each visitor: by setting and tracking a unique value in the cookie. Once a visitor logs in, the unique web server session is bound to the authenticated user making the session identifier equivalent to the username and password. To further compound the issue, the contents of the cookie are automatically transmitted over the network with each request that the browser issues to the webserver.
Once an attacker has sniffed the contents of the web application’s cookie from the network, they have obtained the key component for impersonating the victim on the target site:
Social Networks – an attacker can perform smear campaigns by posting items to the targeted profile for the victim’s contacts to see.
WebMail – an attacker can create a mail filter to read the victim’s email. This attack has already resulted in a blogger being victim to domain hijacking.
Administration Interfaces – an attacker can perform unauthorized changes to devices or services which utilize administrative interfaces to update settings.
Financial Applications – an attacker could steal money or financial information on vulnerable web applications. (Applications which accept credit card payments are subject to PCI-DSS compliance and lack of encryption would no comply. Sites who only accept PayPal or other online payment processors are not subject to PCI-DSS).
Application users must learn to recognize when they’re being misinformed about risk and demand more security from the vendors. Application designers and vendors must implement encryption for the entire application. If the additional server resources are of concern, a hardware appliances for SSL/TLS can be installed so that the web server does not suffer from the overhead resource consumption.
Most modern web applications built on web development frameworks (PHP, Java, .NET, etc) use the cookie to store session identifiers which track a visitor’s activity throughout the site. Moreover, these session identifiers are also used when determining the visitor’s identity and authorizing transactions throughout the web application. As such, this value, which is transmitted with every HTTP request as part of the cookie, becomes a very attractive target to attackers.
To minimize the risk of exposing the session identifier on the network in cleartext the data going between the visitor’s web browser and the web application server must be encrypted using SSL. Baring any other vulnerabilities in the code such as XSS, code injection or SQLi one would assume that the session identifier is well protected…Not if the Secure only cookie flag hasn’t been set.
The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie.
The user agent (possibly under the user’s control) may determine what level of security it considers appropriate for “secure” cookies. The Secure attribute should be considered security advice from the server to the user agent, indicating that it is in the session’s interest to protect the cookie contents.
This excerpt of the RFC simply means that if a cookie has the “Secure” option enabled, the browser must only send the cookie when the HTTP request is performed over SSL. The importance of this option is highlighted by a recent attack by Sandro Gauci of Enable Security.
In his paper (and video), Sandro demonstrates how an attacker on the same network physical network can use his tool (SurfJacking) to hijack another user’s authenticated SSL session with GMail and successfully obtain the session identifier. His approach is so simple, I regret not having thought about this myself:
Victim uses the same browser to visit another web page (while keeping the GMail window open)
The SurfJacking tool detects step 3 and issues a fraudulent 302 HTTP Response code (Permanently Moved) pointing to http://mail.google.com
The victim browser accepts the redirect and initiates a connection with http://mail.google.com using the same session identifier as was used in the SSL connection.
SurfJacking identifies the cleartext GMail session identifier and logs it for the tool operator.
Attacker accessing the victim’s GMail account.
* The browser connection setting in GMail must be set to Don’t always use HTTPS (which is the default)
Sandro Gauci has written a paper and created a video demo to illustrate the attack. The video shows the SurfJacking tool in action as well as mitigating the attack by enabling SSL only cookies with the “browser connection” setting in GMail. Please be sure to check them out.
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.
In order to effectively implement my 
I’ve posted a couple research papers that I’ve written recently.
As a web application security testing professional, you often encounter “snake oil” security implementations. A recent example would be the “
Most modern web applications built on web development frameworks (PHP, Java, .NET, etc) use the cookie to store session identifiers which track a visitor’s activity throughout the site. Moreover, these session identifiers are also used when determining the visitor’s identity and authorizing transactions throughout the web application. As such, this value, which is transmitted with every HTTP request as part of the cookie, becomes a very attractive target to attackers.
DandyID
Friendfeed
claimID
Disqus
Facebook
Twitter
myOpenID
Google Profiles
Linkedin