Skip to main content

Computer Systems Security Planning for Success

Dr. Jan Pearce, Editor

Section 5.5 Web-based Attacks

The world wide web and the protocols/formats/languages it uses (HTTP, HTML, JavaScript, etc.) were not originally designed with security in mind. By default, web pages trust the content they receive to not be malicious. Scripts, commands, cookies, etc. are implicitly trusted. Web technologies have become so popular that they are a common target for attackers and developers must use tokens, sanitize data, and check inputs if they want those technologies to be secure.
🔗
The Open Web Application Security Project (OWASP)
 1 
owasp.org/
is a great source of resources for web application security. They maintain a top 10 list of web application security risks. As of 2021, the OWASP top 10
 2 
owasp.org/www-project-top-ten/
is:
🔗
🔗

Subsection 5.5.1 XSS

Cross-Site scripting refers to the process by which a bad actor can inject a script into a website. Recall that many websites take inputs from forms and may later display that data on another page. If that data isn’t just data, but actually a JavaScript script, that script may run on the page that displays it.
🔗
Using this technique attackers can access cookies, session tokens, and other sensitive information. Depending on where the script was injected and how the server displays that data the script could be stored permanently on the target server. XSS scripts may also be reflected, typically sent in links, where they are only used for one session.
🔗
To mitigate XSS risks, it is important that a web developer sanitize their inputs. When a form is submitted, the website should check that the data submitted isn’t a script or other malicious content. If the data does cannot be cleaned, it shouldn’t be stored or used.
🔗

Example 5.5.1. Samy Worm.

One October 4th, 2005 an XSS worm spread across MySpace, the dominant social network at the time. The worm was written by Samy Kamkar as a simple post that when read would cause a viewers machine to make their own post stating "but most of all, samy is my hero" and including the code to propagate. The results was that within 20 hours over one million users had run the payload.
🔗
Now Samy is a prominent security consultant and you can read his full technical explanation of the worm here
 3 
samy.pl/myspace/tech.html
. Vice Motherboard also did a segment on Samy for their Greatest Moments in Hacking History series
 4 
www.youtube.com/watch?v=DtnuaHl378M
.
🔗
🔗
🔗

Subsection 5.5.2 CSRF

Cross-Site Request Forgery (CSRF) involves using an victims already authenticated session in a request that is not part of that session. Imagine you are logged into Twitter. An attacker sends you a form link in GMail, that when clicked on posts a tweet that says, "I’m a CSRF victim." Assuming Twitter accepts the form submission you will now have a tweet in your timeline that states "I’m a CSRF victim."
🔗
This is probably the most benign scenario, you can imagine things be much worse with an online banking application. The solution is for the website (Twitter in this case) to use a CSRF token (which it does). When the form is generated, a random value is included as a hidden input. That random, hidden input is the CSRF token. When a submission is made, if the CSRF token submitted does not match the one created for the form (which only the valid website knows) the submission is not accepted.
🔗
CSRF tokens are yet another example of how web applications require proactive security as opposed to being secure by design. Most web apps are employing them, but it can be easy for a developer to forget.
🔗
🔗

Subsection 5.5.3 SSRF

Diagram illustrating a Server-Side Request Forgery (SSRF) attack where an attacker tricks a web server into making requests to an internal network resource.
The diagram shows an "Attacker" located on the "Internet," a public-facing web server labeled "example.com" that appears to bridge the "Internet" and an "Intranet," and an internal server identified by the IP address "10.0.0.1" within the "Intranet." The attack begins when the "Attacker" sends a specially crafted GET request to "example.com." This request includes a URL parameter, such as "content=http://10.0.0.1/secret," which points to a resource on the internal server. The vulnerable "example.com" server processes this parameter and, as a result, makes a "Request" on behalf of the attacker to the internal "10.0.0.1" server for the "/secret" resource. The internal server "10.0.0.1" then sends a "Response" containing the requested data back to "example.com." Finally, "example.com" relays this "Response: secret" back to the "Attacker" on the Internet. This flow demonstrates how the attacker exploits the SSRF vulnerability in "example.com" to access and exfiltrate data from an internal system that would otherwise be inaccessible from the public Internet.
🔗
Figure 5.5.2. Server-Side Request Forgery (SSRF)
🔗
Web systems often communicate with internal servers the retrieve information. These may be API servers, databases, or messaging servers. If an attacker can fool a web server into passing a malicious request to its internal server, the attacker and abuse the internal trust of the system. This is referred to a server-side request forgery (SSRF). Once again, this kind of attack is mitigated with input validation, which needs to be included in the application.
🔗
🔗

Subsection 5.5.4 Session Hijacking

Session hijacking may involve other methods of compromise, but the end goal is to "steal" a session between the victim and another server. Imagine the following scenario: A person logs in to their personal banking website, which issues them a cookie which proves they are authenticated. A bad actor is monitoring the connections through an XSS exploit that forwards all connection cookies to them. The bad actor uses the cookie that was issued to make a transfer from the user’s bank account to the bad actors bank account.
🔗
Depending on the method used, session hijacking may be prevented through use of a better session key or by requiring transport layer security (TLS) to connect. In the above scenario the only way to prevent session hijacking would be to repair the initial XSS vulnerability.
🔗
🔗

Subsection 5.5.5 SQL Injection

As mentioned in the SSRF section, almost all web systems are supported by other servers running internally. One of the most common scenarios is to have a web server which reaches out to an internal database. Relational databases utilize structured query language (SQL) so a web application may generate many different SQL queries during its regular operations. If a user input is placed directly into the query, it can be possible to make the result function in a way that was not intended or yield secret information from the database.
🔗
Take a look at the following PHP code:
🔗
$userName = $_POST['user_name']
$pw = $_POST['password']
$statement = "SELECT * FROM users WHERE name='" + $userName + "' AND password='" + $pw + "';"
In the case where the user_name admin and the password password were submitted, the following SQL would be generated: SELECT * FROM users WHERE name='admin' AND password='password';
🔗
In the case where the user_name admin and the password ' OR 1=1; were submitted, the following SQL would be generated: SELECT * FROM users WHERE name='admin' AND password='' OR 1=1;
🔗
In this second case, a user could login without needing a valid password.
🔗
🔗

Subsection 5.5.6 XML Injection

XML stands for extensible markup language, and it is often used to transfer messages. XML can be an important part of a web systems infrastructure and as such if unsanitized user inputs are allowed to generate XML the is used in the system many things can go wrong. Using XML injection an attacker may be able to retrieve secret files or create admin accounts. XML injection can be mitigated by input validation or possibly disabling the resolution of external entities in the framework being used.
🔗
🔗

Subsection 5.5.7 LDAP Injection

Finally, Lightweight Directory Access Protocol (LDAP) is often used to store information about users. As such, it can be found behind many web applications. LDAP also supports complex queries in a similar fashion to SQL. An unsantized user input can lead to a LDAP query with unexpected results.
🔗
🔗

Subsection 5.5.8 Directory Traversal

A poorly designed web server may be subject to a directory traversal attack. Recall that web servers are designed to serve static content from a particular directory, /var/www for example. Now suppose that an attacker submitted a GET request for http://www.example.com/../../etc/shadow. It is possible that the web server may actually go up two directories and serve that file.
🔗
This can be addressed with file permissions, access controls, and filtering incoming requests. It is important to note that there is more than one way to specify a path in an HTTP request, including using URL encoding, so all possible malicious inputs must be sanitized.
🔗
🔗

Subsection 5.5.9 URL Typosquating

An unfortunately common, broad-based attack is to buy a domain with a similar name to a very popular domain. When users mistype the popular domain they end up at the malicious actor’s website. For example, imagine if someone registered gooogle.com (note the three o’s). They could gain a lot of traffic from people who mistyped google.
🔗
These sites could be used for ad revenue, phishing credentials, or even possibly to distribute malware. A mitigation that several browsers implement is to keep a list of malicious websites and warn users before they visit them.
🔗
🔗

Subsection 5.5.10 Domain Hijacking

Domain names expire after a certain period of time and the registrant may forget to renew. In these rare occasions an attacker may actually gain control of a popular domain name, google.com for example, and route traffic to their site. The malicious activities are the same as for typosquating, but the attacker does not need to rely on the users making a mistake.
🔗
It is also possible to hijack a domain by logging into the domain registration system using stolen/compromised credentials. In this scenario an attacker could still modify a record to point to their server, but wouldn’t have to rely on the company forgetting to renew.
🔗
🔗

Subsection 5.5.11 Zone Transfer Attacks

On the subject of the domain name system, zone transfer attacks may leak sensitive information about domains. DNS is a distributed system by design and is used for resolving domain names into IP addresses. Due to the distributed nature of the system, protocols were built in for having a single domain served by multiple servers. These servers pass information to each other using a DNS zone transfer.
🔗
Typically these communications should be internal as they may leak valuable information regarding the zone. Unfortunately an improperly configured DNS server may advertise its zone transfers publicly. In such a situation an attacker can use the leaked information in the recon phase of an attack.
 5 
digi.ninja/projects/zonetransferme.php
🔗
🔗

Subsection 5.5.12 Clickjacking

A website may be designed in such a way that the interface is confusing to the user and they inadvertently click on an advertisement or malicious link. This is common practice on low integrity websites such as streaming sites, torrent trackers, and adult websites. It is often complicated by a poor ad screening or even purposefully making ads that look similar to the content.
🔗
🔗
You have attempted 1 of 1 activities on this page.
🔗
PrevTopNext