 |
Redspin SMA Sign Up!
|
|
Sign yourself or a colleague up for our free Redspin Security Management Advisory monthly newsletter. We will not share your email address.
|
|
* = Required Information
|
 |
|
|
|
 |
|
|
|
 Back To Redspin Security Management Advisory Headlines
|
 |
Volume 3 | June 4, 2008
|
 |
|
Executive Summary — Why Site Defacement Risk Matters
Web sites hosting home banking or shopping cart applications are complex and provide many opportunities for mistakes that can lead to unintended personal information disclosure. In fact, even the most basic "brochure ware" website can be a means of stealing customer information. Because the complex features of a bank's website are usually outsourced to a large service provider, it becomes quite easy to ignore the security risks stemming from a simple informational homepage. However, site defacements can be extremely damaging to the reputation of an organization, regardless of whether or not confidential data has been compromised. As this discussion points out, site defacement attacks can also go one step further and compromise the integrity of login forms on the site, allowing an attacker to intercept and steal customer data.
|
Redspin's experience with hundreds of websites demonstrates that vulnerability to defacement and page modification has not improved significantly, especially amongst the most basic "brochure ware" sites. People tend to correctly associate complexity with increased security risk, and this assumption explains, in part, why so many basic websites are often assumed to be secure. It may seem impossible for a simple site to be compromised, but next-generation defacement attacks pose a serious risk to financial institution websites. It is now fairly easy for potential attackers to locate vulnerable sites in mass by appropriating the power of search engines and technical search strings.
Alarmingly, site defacement attacks can actually go one step further through techniques designed to breach customer information. One basic example of how website defacement could lead to a breach of customer data would be if someone modified the customer login form so that username and passwords were sent to an unauthorized server owned by an attacker, instead of to the bank's legitimate server. Modifying the login function in just this very subtle way allows attackers to intercept customer data passively, and eliminates the need for an attacker to compromise the internal network. Even just the compromise of several accounts can often entail account and card reissuing costs for the entire customer base, as the extent of a breach can be difficult to determine. This type of impact on a bank's reputation may take tens of thousands of dollars to neutralize and who knows how many damage-control dollars from which to completely recover.
|
|
Example of Basic Site Defacement - Mocked and Simulated on www.redspin.com
The screen shot below is a simulated example "mocked up" on our own website to demonstrate how subtle and trivial this type of defacement attack can be. For the purpose of this discussion, we assume that www.redspin.com does not filter user input, which allows the content of the website to be modified. In this case, we elected to tamper only with the title of the page. This is an example of only a "light" defacement that is easy to demonstrate and accomplish with one input string. While we have only modified the title below, readers should bear in mind that the entire content could have been replaced with highly offensive or illicit content. Furthermore, if login fields existed on the site, it may have been possible to tamper with them in order to intercept authentication credentials.
The following URL creates a cookie named "Tamper" with the value "test," and modifies the title of our website to "Redspin controls your Title." In this case, we have simulated the attack on our own page simply to demonstrate what this general category of injection risk and defacement may look like in practice:
<![CDATA[<a href="http://www.SAS70.com" rel="no follow" target="_blank"]]>
<![CDATA[class="linkBlueLg"><br>http://www.redspin.com/home/index.jsp?]]>
<![CDATA[OPTION=HOME_PAGE&setCountryCode=US&setLocaleCodeSelect=&setLocale]]>
<![CDATA[Code=any%0D%0ASet-cookie:+Tamper=Test%0D%0A%0D%0Ahtml>]]>
<![CDATA[<head><title>Redspin controls your title</title></head></html></a>]]>
Illustration 4: Invalid Character Injection Allows Modification of Title and Webpage Content
|
|
Why Attackers Have Shifted Attention from the Conventional to the Web-Based
Web based attacks over HTTP & HTTPS have become a common means of bypassing traditional network-layer controls such as the firewalls, intrusion detection systems, and DMZ's. As we discussed in the April Redspin Newsletter, firewalls often have configuration errors, yet firewall technology is fairly well proven and the attention of malicious attackers has shifted away somewhat from more conventional attacks to web based attacks over HTTP/HTTPS.
The Open Web Application Security Project (OWASP, www.OWASP.org) raised injection attacks (such as the one mocked above on our website) to 2nd position this year on their Top 10 list of web application security vulnerabilities: "Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data."
www.owasp.org/index.php/Top_10_2007
|
|
Injection Attacks Require Awareness - Not More Gear or Costly Automated Scanners
Redspin Website Security Assessments adopt the OWASP methodology for web application security testing and are based off a manual analysis process. This type of process allows a more appropriate framework to pursue the OWASP methodology and allows additional risks to be identified during the course of analysis. Based on the need for bank's to secure their homepage from defacement, Redspin is now offering a reduced cost website security assessment designed to identify site defacement risk specifically for financial institutions who have outsourced their online banking and are primarily concerned about their brochure ware homepage.
As in other areas of security, automated scanners do have an intended and useful purpose. However, even in their more traditional role attempting to identify network-layer vulnerabilities (for example, an unneeded open port or un-patched software), scanners often miss crucial and subtle issues because they do not take into account important contextual factors such as the network architecture or specific business requirements. Even the most proven automated scanning tools require review and analysis by an expert in order for the results to be made intelligible and actionable to management. Web application vulnerability scanners are newer and relatively untested compared to traditional network-layer scanners, and they are not yet able to exhaustively identify every subtle issue that could put your site at risk to defacement. Furthermore, these tools tend to be highly costly and in our analysis the output of these tools often fails in comparison to manual analysis conducted by an expert security engineer. OWASP objectively summarizes the technical difficulties with automated tools as follows:
Automated approaches: Many vulnerability scanning tools search for injection problems, particularly SQL injection. Static analysis tools that search for uses of unsafe interpreter APIs are useful, but frequently cannot verify that appropriate validation or encoding might be in place to protect against the vulnerability. If the application catches internal server errors, or detailed database errors, it can significantly hamper automated tools, but the code may still be at risk.
www.owasp.org/index.php/Top_10_2007-A2
|
|
Technical Security Checklist for the Website Developer
Is the website's code peer reviewed and developed carefully by security-conscious developers? (Is it in-house developed one-off code adopted from Google searches or open source code that has faced widespread scrutiny by security experts)?
Can the developers provide the controls implemented which have addressed the OWASP Top 10 Web Vulnerabilities? (for example: "I have addressed the dangers of cross-site scripting by ensuring that special HTML characters are converted to their HTML representatives.")
Is there any filtering being performed on non-static parts of the website? Is this filtering being referenced from a single location/single function, with a well defined input and output which represents the single point of entry into the database?
What type of filtering is being performed? (Parameterizing SQL,whitelisting, blacklisting, etc.)
Do the developers know the difference between client-side (Javascript) and server-side input filtering? (Client-side can be disabled and is for user convenience only).
Are error pages disclosing useful user information without disclosing sensitive information? Is there a function that prevents content that should never be displayed to the user from being put on the website? (SQL Errors, ASP Errors, Path names, Internal Error Numbers)
When major site upgrades are performed, is the security and validity of the site tested by an independent party that is technically capable of critically reviewing the code for security best practices?
|
|
Speak with a Redspin Security Consultant Today!
|
* = Required Information
|
|
|
|
|
|
|
 |
