# Web Exploitation

## Summary


Websites are significantly more complex today than in the early 1990s when they mostly served static HTML content. Web applications often serve dynamic content, use databases, and rely on third-party web services. The application server itself is being built from many components, which may come from diverse sources. Servers authenticate users before logging them into the system. They also authorize users to access restricted resources or data. Often applications handle sensitive user data that need to be protected.  

Given this complexity, it's not easy to deploy and maintain web applications in a secure way. No application is perfect. Hackers are always on the lookout to discover and exploit vulnerabilities. This article discusses web exploitations and offers tips to improve the security of web applications.

## Discussion

### What aspects of an application are vulnerable to web exploitation?

A web application typically involves a web server, an application server, application middleware, internal or third-party web services, a database, and so on. Any of these components could be attacked. 

An attack could be as simple as slowing down the server by making lots of HTTP requests. More serious attacks would involve installing a virus on the server or stealing sensitive data. Defacing the site by modifying site content, or deleting code or data are just as serious but more easily visible. Another attack is to run cryptocurrency miners on server infrastructure. 

Web clients/browsers and servers communicate via protocols such as HTTP, HTTPS, FTP, etc. Vulnerabilities in how these protocols are used could be exploited. Protocols are located at different layers of the protocol stack. Although web exploits happen at the application layer (layer 7), it can impact other layers via packet flooding (data link layer) or SYN flooding (network layer). However, web exploits at the application layer are becoming more common than network layer attacks on web servers. 


### Which are main types of web vulnerabilities and their related exploits?

Web exploits involve one or more of the following:  

    + **Injection**: This results from accepting untrusted input without proper validation. Examples include SQL injection, LDAP injection and HTTP header injection.
    + **Misconfiguration**: This happens when processes are manual and settings are not correctly maintained.
    + **Cross-Site Scripting**: Via user input, server accepts untrusted JavaScript code. When server returns this in response, browser will execute it.
    + **Outdated Software**: With the increasing use of open source and third-party software packages, it's important to keep these updated. Outdated software can be exploited, especially when the vulnerabilities are public.
    + **Authentication & Authorization**: URL may expose session ID. Password may be unencrypted. If timeouts are not correctly implemented, session hijacking is possible. Unauthorized resources can be accessed even when UI doesn't expose them.
    + **Direct Object References**: By poor design or coding error, direct references are exposed to clients. For example, a GET request to `download.php?file=secret.txt` may bypass authorization and allow direct download of a protected file. Another example is to directly reset admin password.
    + **Data Exposure**: Sensitive data is stored in an unencrypted form, or exposed in cookies or URLs. Client-server communicate on a non-HTTPS connection.

### What are some exploits pertaining to HTTP headers?

One technique is to send an arbitrary domain name or port number in the **Host header** and see how the server responds. Duplicating the Host header or formatting it differently can reveal vulnerabilities. These can be exploited to reset passwords, bypass authentication or poison web cache. 

Suppose your architecture uses a load balancer or reverse proxy, followed by a backend server. Each component might process the HTTP header in subtly different ways. This can lead to **HTTP request smuggling** attacks in which an extra malicious request is smuggled via the main request. 

Newlines are used to separate HTTP header from body. With **CRLF injection**, characters `\r\n` are forced into header fields via their URL encoded form `%0D%0A`. This can be used to modify HTTP access logs to cover up earlier attacks, enable CORS or deliver XSS payload. 

To improve web security, HTTP has headers related to Cross-Origin Resource Sharing (CORS). Some of these are Access-Control-Allow-Origin, Access-Control-Expose-Headers, and Access-Control-Max-Age. More security-specific headers include Cross-Origin-Resource-Policy, Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, and X-XSS-Protection.  


### What are some server-side web exploits?

HTTP DoS attack works by making large number of HTTP requests to the web server. It may also involve crawling the site to learn which pages require more server processing. The attack then involves requesting resource-intensive pages. If requests involve database calls, the site slows down visibly affecting user experience. Another way to slow down the server is to set a high Content-Length header value, send fewer bytes and make the server wait for the rest. 

Remote code execution is possible if server is using outdated software. Once server is infiltrated, arbitrary code can be executed to steal data or install malware. Insecure deserialization is a vulnerability that can lead to remote code execution. 

Improper authentication and authorization can allow attackers access protected server resources or sensitive data. Passwords could be reset via URL query strings. 

Database could be corrupted via SQL injection. This can happen when input data is not validated. 

In any case, it's important that server software is kept up to date. Review and validate configuration. Collect sufficient logs and constantly monitor so that any breach is detected as soon as possible. 


### What is Cross-Site Scripting?

Cross-Site Scripting (XSS) is when a user visits site A and her browser executes malicious script that then contacts site B. Malicious code is contained within `<script>` tag. The user is initially tricked into clicking a link, perhaps via email. The genuine site loads in browser but the attacker has already passed malicious code via the URL. Another variant of the attack is to input code in forms. In either case, the malicious script can access user cookies on the browser. These are sent to the attacker's site to later impersonate the user on genuine sites she uses. 

Although JavaScript code for this attack executes on the browser, XSS attacks have been classified into **Server XSS** or **Client XSS** attacks. In either case, the vulnerability starts with untrusted user input. With Server XSS, the server sends the malicious script in the response. With Client XSS, the DOM is updated to make JavaScript calls. 

Context-sensitive output encoding and input validation can protect against Server XSS. Against Client XSS, call only trusted JavaScript APIs but this is easier said than done. 


### What are the security problems with Flash?

Created in 1996 by Macromedia and acquired by Adobe in 2005, Flash is used to render rich multimedia content on browsers. Increasing use of Flash on the web started to grow in the early 2000s. 

The earliest reported security vulnerability with Flash dates from 2005. As of October 2020, Flash has gathered more than 1000 vulnerabilities. Number of vulnerabilities are 8 (2019), 26 (2018) and 65 (2017). Types of vulnerabilities include code execution, overflow, memory corruption, DoS, bypass of access restrictions, access to sensitive information, and more. XSS attacks are possible via what's called **Flash Parameter Injection (FPI)**. 

As an example, CVE-2017-11292 allowed arbitrary code execution. A flawed bytecode verification procedure meant that an array index could be derived from an untrusted value. This led to type confusion and malicious code execution. 

**Flash cookies** are also problematic. They have been misused to track users across sites they visit. Users can't easily disable them, unlike HTTP cookies. 

Flash is not open source. HTML5 is the standardized way to deliver multimedia content. Due to the many security issues, browser vendors and Abode announced in 2017 that Flash will be discontinued from January 2021. 


### What are some common misconfigured security settings?

An application may have a debug mode that results in lots of internal information printed out. By mistake, this mode is used in production. Even without the debug mode switched on, it's possible that the application shows stack traces when an error occurs. Another mistake is to allow the server to list directory contents. This exposes internal directory structure and contents to attackers. 

Software components come with default values. For example, MySQL server uses a default username and password, unless the admin changes them to non-default values. If application is deployed with default values, it's easy for an attacker to exploit this. 

It's a flaw to store passwords in code or read them from files committed to the code repository. A better way is to set passwords as environment variables that the application can access. 

A web server offers its service on well-known default ports. At the minimum, it may offer HTTP on port 80 and HTTPS on port 443. Running other services on the server, many of which may be unnecessary or unused, opens up a larger attack surface. 


### Could you share real-world instances of web exploits?

Data breaches have affected many big names including Adobe, eBay, Equifax, LinkedIn, Marriott International, Sina Weibo and Yahoo. The biggest breach is perhaps Yahoo's in 2013-14 involving 3 billion user accounts. 

eCommerce sites have been hacked. British Airways was attacked in 2018 leading to stolen customer details. The problem was down to a third-party JavaScript that had not been updated since 2012. In 2019, fashion retailer Sweaty Betty become victim to malicious JavaScript injection. 

The Panama Papers leak of 2016 happened due to outdated software. In fact, the site had many vulnerabilities including authentication and SQL injection. An example of XSS exploitation is Steam profile hack of 2017. JavaScript was injected into user profile page. This was used to drain Steam Wallet funds or spread other malware. Vulnerable since 2008 but discovered only in 2017, the REST plugin of Apache Struts 2 did deserialization in an insecure manner leading to arbitrary code execution. 

Cloud infrastructure is not immune to attacks. Australian Broadcasting Corporation and Accenture are examples of organizations that failed to adequately protected their Amazon S3 storage instance. They were attacked in 2017. 


### Could you share some best practices to make web applications more secure?

Make your application code more secure but this is often hard. Instead, adopt a framework with built-in security features and functions. 

Penetration testing must be part of your process. When vulnerabilities are discovered, fix them at the earliest. Automate processes. Use a Web Application Firewall (WAF) as a preventive measure. Design applications in a modular way so that it's easier to apply attributes on resources. 

When using third-party components, ensure you're using the correct one and not a typosquatted package. Keep them updated to take advantage of latest security fixes. 

Always sanitize user inputs. Avoid blacklists since they're brittle. Whitelists are better. If returning HTML tags from user input to browser, encode the tags. For example, return `<script>` as `&lt;script&gt;`. 

Don't include user inputs in HTTP headers. In HTTP headers, encode CRLF special characters. Adopt security headers such as Content Security Policy and X-XSS-Protection to protect against XSS and code injection. X-Content-Type-Options counters MIME sniffing. X-Frame-Options counters clickjacking. Strict-Transport-Security enforces communication over HTTPS.  

For authentication, issue new cookies when user logs in or changes role. Limit session duration. Set cookies with attributes HttpOnly, Secure and SameSite=Strict. 


### What online resources are available to know about current web vulnerabilities?

Software vulnerabilities are categorized and named individually to help developers and security researchers. These are formalized as **Common Vulnerabilities and Exposures (CVE)**, a system initiated by the MITRE Corporation. 

Among the useful databases are National Vulnerability Database (NVD) from NIST, Vulnerability Assessment Platform (Vulners), Vulnerability Database (VulDB) and CVE Details. Vulners offers a useful search functionality and it's been called "Google for hackers". VulDB documents vulnerabilities in electronic products. MITRE's own database is called Common Weakness Enumeration. MITRE and NIST work closely. 

Exploits of these vulnerabilities are also documented and organized as **exploit databases**. Among the well-known ones are ExploitDB, Rapid7, CXSecurity, Vulnerability Lab, Oday, SecurityFocus, Packet Storm Security, and Google Hacking Database. 

**Tools** are also available for security testing of web applications. Some of these include Zed Attack Proxy (ZAP) from OWASP, Wfuzz, Wapiti, W3af, SQLMap, SonarQube, Iron Wasp, Metasploit, Nessus, Burp Suite, Nikto, and OpenVAS. More tools to scan a site for vulnerabilities include SUCURI, Qualys, Quttera, Intruder, UpGuard, Web Cookies Scanner, Detectify, Probely, and Pentest-Tools. 

## Milestones

1990

In the early 1990s, the World Wide Web (WWW) starts to grow. Most websites serve only static pages, thus presenting few security vulnerabilities. From mid-1990s, more websites start to adopt JavaScript, thus presenting opportunities for the first web exploits. 

Sep  
1999

As a public list of known vulnerabilities, the **CVE List** is launched. The original list contains 321 entries. By December 2000, 29 organizations claimed to offer "CVE-compatible" products and services. Later, CVE List becomes the basis of U.S. Government's National Vulnerability Database (NVD). In 2011, ITU-T adopts CVE List. As of October 2020, the list includes more than 140,000 entries. 

2000

**Cross-Site Scripting (XSS)** is first discovered at Microsoft. It's believed that XSS is due to server-side code. By 2005, it's clear that XSS is possible at the client side as well. Although client-side XSS was possible even in 1997, it starts to increase from 2003 with the coming of Web 2.0. This exploit continues to grow for many years and starts to fall only from 2013. 

2005

From mid-2000s, the use of JavaScript increases in terms of key metrics: more JavaScript statements per external script that's included, inclusion of scripts from more domains, and higher code complexity. These are indications of richer user interactions and push of application logic towards the client. 

2017

At the 26th USENIX Security Symposium Stock et al. give the example of Firefox browser. It supports 83 different APIs whereas it supported only 12 APIs back in 2006. This growth has led to many vulnerabilities on the client side. 

2019

Edgescan SaaS application reports that web applications pose a greater risk than applications exposed at the network layer. About 35% of vulnerabilities in web apps are of high or critical risk. On average, it takes 85 days to fix a web app vulnerability. A 20-year vulnerability about SNMP community name is discovered. The most common vulnerability is a birthday attack on long-duration encrypted HTTPS sessions. 

2019

A study from Positive Technologies shows that 9 out of 10 websites can be hacked, 39% allow unauthorized access, and 68% can suffer from data breaches. Application code account for 82% of the vulnerabilities. Security misconfiguration is the most common one. XSS attacks exploiting cookies that didn't use HttpOnly and Secure flags affect one out of five tested applications.