Web Exploitation

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?
    Modern web architecture is complex with many parts and interfaces. Source: Futon 2017.
    Modern web architecture is complex with many parts and interfaces. Source: Futon 2017.

    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?
    With HTTP request smuggling, the frontend server sees one /home request while the backend server sees /home and /admin requests. Source: PortSwigger 2020c.
    With HTTP request smuggling, the frontend server sees one /home request while the backend server sees /home and /admin requests. Source: PortSwigger 2020c.

    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?
    Typical steps in an XSS exploit. Source: Cloudflare 2020.
    Typical steps in an XSS exploit. Source: Cloudflare 2020.

    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?
    Screenshot from Burp Suite showing SQL injection via URL query string. Source: PortSwigger 2020d.
    Screenshot from Burp Suite showing SQL injection via URL query string. Source: PortSwigger 2020d.

    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
Web technologies used by top 500 sites. Source: Stock et al. 2017, fig. 2.
Web technologies used by top 500 sites. Source: Stock et al. 2017, fig. 2.

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 shows that most vulnerabilities were found in 2018. Source: Edgescan 2020, pg. 8.
Edgescan Saas shows that most vulnerabilities were found in 2018. Source: Edgescan 2020, pg. 8.

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
Common vulnerabilities of 2019. Source: Positive Technologies 2020.
Common vulnerabilities of 2019. Source: Positive Technologies 2020.

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.

References

  1. Acunetix. 2014. "Elaborate Ways to Exploit XSS: Flash Parameter Injection (FPI)." Blog, Acunetix, April 8. Accessed 2020-10-26.
  2. Biplov. 2020. "Handling Passwords and Secret Keys using Environment Variables." Dev.to, April 7. Accessed 2020-10-26.
  3. Borges, Esteban. 2019. "What is CVE? - Common Vulnerabilities and Exposures." Blog, SecurityTrails, December 10. Updated 2020-10-27. Accessed 2020-10-26.
  4. Borges, Esteban. 2020. "Top 8 Exploit Databases for Security Researchers." Blog, SecurityTrails, February 11. Updated 2020-10-23. Accessed 2020-10-26.
  5. Brown, Tim. 2017. "What's an SSL port? A technical guide for HTTPS." GoDaddy, November 2. Accessed 2020-10-26.
  6. CVE Details. 2020. "Adobe » Flash Player : Security Vulnerabilities." CVE Details. Accessed 2020-10-26.
  7. Cloudflare. 2020. "What Is Cross-Site Scripting?" Cloudflare. Accessed 2020-10-26.
  8. Edgescan. 2020. "2020 Vulnerability Statistics Report." Edgescan, BCC Risk Advisory Ltd. Accessed 2020-10-26.
  9. Fulton, Jonathan. 2017. "Web Architecture 101." Storyblocks, November 8. Accessed 2020-10-26.
  10. Grinaker, Siw. 2019. "Websites: past and present." Blog, Enonic, January 19. Accessed 2020-10-26.
  11. Herrman, John. 2010. "What Are Flash Cookies and How Can You Stop Them?" Popular Mechanics, September 23. Accessed 2020-10-26.
  12. Infosec Institute. 2019. "Top 7 Web Application Penetration Testing Tools." Infosec Institute, January 16. Accessed 2020-10-26.
  13. Kalman, Gergely. 2014. "10 Most Common Web Security Vulnerabilities." Toptal, May 29. Accessed 2020-10-26.
  14. Kumar, Chandan. 2020. "11 Online Free Tools to Scan Website Security Vulnerabilities & Malware." Geekflare, March 21. Accessed 2020-10-26.
  15. Lerner, Robert. 2019. "Hidden Helpers: Security-Focused HTTP Headers." Blog, Rapid7, May 30. Accessed 2020-10-26.
  16. Lupesko, Hagay. 2017. "How To Secure Your Web App With HTTP Headers." Smashing Magazine, April 3. Accessed 2020-10-26.
  17. MDN Web Docs. 2020. "HTTP headers." MDN Web Docs, Mozilla, April 27. Accessed 2020-10-26.
  18. Nader, Youssef. 2020. "Top 10 Open Source Security Testing Tools for Web Applications." Blog, Hackr, September 11. Accessed 2020-10-26.
  19. Netsparker. 2019. "CRLF Injection and HTTP Response Splitting Vulnerability." Blog, Netsparker, May 23. Accessed 2020-10-26.
  20. OWASP. 2020. "OWASP Top Ten." OWASP, June 7. Accessed 2020-10-26.
  21. OWASP. 2020b. "Types of XSS." OWASP, August 27. Accessed 2020-10-26.
  22. Palmer, Danny. 2017. "Hackers race to use Flash exploit before vulnerable systems are patched." ZDNet, October 20. Accessed 2020-10-26.
  23. Phatak, Prashant. 2012. "Cyber Attacks Explained: Web Exploitation." Open Source For You, March 25. Accessed 2020-10-26.
  24. PortSwigger. 2020a. "How to identify and exploit HTTP Host header vulnerabilities." PortSwigger. Accessed 2020-10-26.
  25. PortSwigger. 2020b. "HTTP request smuggling." PortSwigger. Accessed 2020-10-26.
  26. PortSwigger. 2020c. "Exploiting HTTP request smuggling vulnerabilities." PortSwigger. Accessed 2020-10-26.
  27. PortSwigger. 2020d. "Using Burp to Exploit SQL Injection Vulnerabilities: The UNION Operator." PortSwigger. Accessed 2020-10-26.
  28. Positive Technologies. 2020. "Web Applications vulnerabilities and threats: statistics for 2019." Positive Technologies, February 13. Accessed 2020-10-26.
  29. Stock, Ben, Martin Johns, Marius Steffens, and Michael Backes. 2017. "How the Web Tangled Itself: Uncovering the History of Client-Side Web (In)Security." Proceedings of the 26th USENIX Security Symposium, USENIX Association, pp. 971-987, August 16-18. Accessed 2020-10-26.
  30. Sukianto, Axel. 2020. "Real Life Examples of Web Vulnerabilities (OWASP Top 10)." Blog, Horangi, June 19. Accessed 2020-10-26.
  31. Swinhoe, Dan. 2020. "The 15 biggest data breaches of the 21st century." CSO, April 17. Accessed 2020-10-26.
  32. TablePlus. 2018. "What is the default username and password in MySQL?" Blog, TablePlus, November 14. Accessed 2020-10-26.
  33. Tannam, Ellen. 2019. "What were the top 10 web exploits used by malicious attackers in 2018?" Silicon Republic, January 16. Accessed 2020-10-26.
  34. Taylor, Matthew, Ruturaj K. Vaidya, Drew Davidson, Lorenzo De Carli, and Vaibhav Rastogi. 2020. "SpellBound: Defending Against Package Typosquatting." arXiv, v1, March 6. Accessed 2020-10-26.
  35. Thakkar, Jay. 2018. "HTTP Security Headers: 5 Headers You Must Implement on Your Site." Hashed Out Blog, The SSL Store, April 2. Accessed 2020-10-26.
  36. The MITRE Corporation. 2018. "History." Common Vulnerabilities and Exposures, The MITRE Corporation, December 10. Accessed 2020-10-26.
  37. The MITRE Corporation. 2020. "CVE List Home." Common Vulnerabilities and Exposures, The MITRE Corporation, May 15. Accessed 2020-10-26.
  38. Wikipedia. 2020. "Adobe Flash Player." Wikipedia, October 13. Accessed 2020-10-26.
  39. Wright, Alex. 2020. "5 lessons to learn from high-profile hacks." Raconteur, July 9. Accessed 2020-10-26.

Further Reading

  1. Kalman, Gergely. 2014. "10 Most Common Web Security Vulnerabilities." Toptal, May 29. Accessed 2020-10-26.
  2. Stock, Ben, Martin Johns, Marius Steffens, and Michael Backes. 2017. "How the Web Tangled Itself: Uncovering the History of Client-Side Web (In)Security." Proceedings of the 26th USENIX Security Symposium, USENIX Association, pp. 971-987, August 16-18. Accessed 2020-10-26.
  3. Sophos. 2018. "Exploits Explained: Comprehensive Exploit Prevention." Whitepaper, Sophos, March. Accessed 2020-10-26.
  4. Geekflare. 2020. "7 Best Practices to Secure a Static Website." Geekflare, August 1. Accessed 2020-10-26.
  5. Ollmann, Gunter. 2007. "HTML Code Injection and Cross-Site Scripting." XSSed, May 21. Accessed 2020-10-26.
  6. CISA. 2020. "Alert (AA20-133A): Top 10 Routinely Exploited Vulnerabilities." CISA, Dept. of Homeland Security, May 12. Accessed 2020-10-26.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
User avatar sangeetha-prabhu
2
0
2347
Avatar of user arvindpdmn arvindpdmn
1
2
66
DevCoins due to articles, chats, their likes and article hits are included.
2485
Words
2
Authors
3
Edits
2
Chats
2
Likes
15K
Hits

Cite As

Devopedia. 2020. "Web Exploitation." Version 3, October 28. Accessed 2024-06-25. https://devopedia.org/web-exploitation
Contributed by
2 authors

Last updated on
2020-10-28 06:06:52

Improve this article
web security authorization javascript authentication

See Also

Article Warnings

  • In References, replace these sub-standard sources: geekflare.com
  • In Further Reading, replace these sub-standard sources: geekflare.com