11.6 Deployed Applications and Web Applications

Last updated
Save as PDF

Page ID: 91542

\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

Subtopic

Software security does not stop at the time the software is shipped! Particularly in cases where the software is a web application and the software is used constantly by users all over the world. Additionally, web applications are accessible from nearly anyone in the world, making them a target for attacks.

This chapter focuses on software as it is being designed and developed, but a quick look into the last 3 of the OWASP Top 10 rounds out the chapter.

A05:2021-Security Misconfiguration

Misconfigured software happens frequently; most of the time the consequences are not large but sometimes sensitive data may be leaked.

Stack Traces

A "stack trace" describes where in the code an error occurred. So called "stack traces" are helpful when developing code and debugging failures. However, stack trace data can sometimes contain sensitive or proprietary information. As such, a stack trace should never be displayed to a user. The image below indicates an actual stack trace from a web application.

The image shows the message: "An unhandled error has occurred in the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code — Figure \(\PageIndex{1}\): Server Error in web application (CC-BY-SA)

Note that the stack trace suggests some very useful information for a hacker. In particular, consider:

A fully qualified directory name exists - this might be useful for a path traversal attack
The "GetSiteByDomain(servername)" function suggests that perhaps other sites use this software; maybe an nslookup or whois would lead to other sites which can be compromised

Be sure to look at the OWASP45 page for more details.

A09:2021–Security Logging and Monitoring Failures

This refers to two separate but related concepts:

Security Logging - persisting an audit trail such that details of how a breach occurred are available after the fact in order to provide evidence
Monitoring - observing user behavior, often by referencing logs and audit trails, in real time or close to real time

Security logging is useful in order to keep a record of what is happening at any point in time within the system. Logging alone will not prevent an attack, but it will make it easier to figure out what happened.

Conversely, monitoring the system (and often the security logs) is a way to identify attacks in real time or discover that an attack occurred after the fact. With the rise of artificial intelligence or machine learning, coupled with the sharp rise in cyber attacks and ransomware attacks, real time monitoring is becoming a big market for software vendors.

Be sure to look at the OWASP page⁴⁶ for more details.

A10:2021–Server-Side Request Forgery (SSRF)

Rounding out the OWASP Top 10 is server side request forgery⁴⁷. As web browsers become more advanced and security aware, SSRF attacks are not as commonplace as they once were.

Bank Example

To better understand this scenario, follow this example:

A user logs into their online bank using a web browser
The user does not log out, but navigates to a malicious page
The malicious page can, behind the scenes, send a request to the users bank in order to transfer money from the users account into the attackers bank account

This happens because the attacker is able to take advantage of the way web browsers work. In particular, any cookie associated with a website is sent with each request to that site. Additionally, session information is often stored in a cookie. That means that any request from a web browser to a specific web site will result in the cookie being sent, regardless of who told the browser to send the request. All the attacker needs to do is:

Hope that a user is logged into a bank website (https://www.myinsecurebank.com)
Convince the user to visit the a malicious site (https://www.mymaliciouswebsite.com)
The malicious site can use JavaScript in order to send a request from the user's browser to the user's bank website (https://www.myinsecurebank.com) in order to transfer funds

From the bank website's perspective, nothing is amiss as the user has valid cookies and valid session information. From the user's perspective, there is no visual indicator that any attack happened and the attack will go unnoticed until the user checks their balance at some point later.

Server-Side Request Forgery is a collection of techniques to prevent attacks of this nature. Mitigation tactics can be found on the OWASP page⁴⁸ for this vulnerability.