35
Web Security Attacks You Must Know – Part 1
As developers, we know the pitfalls of the internet – the gateways that malicious actors can exploit to steal private data, siphon money and generally wreak havoc. But if we’re going to build watertight applications, it’s essential that we keep updating our knowledge base and prepare for every possible assault.
In this post, we’re going to discuss five particularly common forms of attack. We’ll discuss more examples in future articles, but these ‘big five’ should form the basis of your security regime.
Web security (or web application security) attacks are those activities performed to exploit the weaknesses and vulnerabilities of an application.
Usually there are two parties involved in an attack: the attacker (criminal) and the victim (user).
These are the people who target a system, user or account to gain access for illegal purposes. Once they’ve gained access, they steal data, money, credentials and other essential assets. An attacker could be a human, a program or a bot in any part of the world.
This is the person who is adversely impacted by the attacker. Anyone can fall victim to malicious online activity if they don’t take the necessary precautions; some victims are not particularly internet-savvy, but others possess a significant amount of knowledge. Victims are exposed to their attacker by the exploitable vulnerabilities of the applications they use on a daily basis.
In this article we’re going to focus specifically on the following attacks:
There are other attacks to consider, like SQL Injection, Brute Force, DoS, DDoS and many more… but we’ll save those for future articles.
In Cross-Site Scripting (XSS), attackers inject malicious script into a legitimate website link and send it to the victim. The attacker identifies the website as a target for attack after assessing its weakness and vulnerability. The victim usually receives the link embedded in an e-mail message.
Many browsers are unable to detect malicious code. So when the victim clicks on the link, the browser concludes that the link came from a trusted source, loads the site and executes the malicious script. Once executed, the script can collect sensitive information, tokens and cookies stored in the browser and send them to the attacker. The attacker then makes use of this stolen information without the victim’s knowledge.
The picture below shows the interactions between an attacker and a victim when the
XSS attack takes place.
We categorize XSS in three general categories:
Reflected XSS Attack, the attacker uses the target URL with a malicious script. The script executes and modifies the browser’s document object model (DOM).Here are a few examples of script injections based on various events:
<body onload=alert(1)> – Fires when the element loads.<style>@keyframes x{}</style><xss style="animation-name:x" onwebkitanimationstart="alert(1)"></xss> – Fires when a CSS animation starts.As is the case with any other type of security attack, the attacker can inject a malicious script only when the website or application is vulnerable. So the best way to prevent the attack is to take the necessary precautions. By doing the following, you will go a long way to preventing XSS attacks:
HttpOnly flag to true – When you set the HttPOnly flag to true for cookies, it cannot be accessed by the client-side JavaScript. It’s standard security practice to safeguard this flag from XSS-type attacks.Let’s move onto the next type of attack,
Phishing. In a phishing attack, the attacker poses as a legitimate party to send the victim e-mails or text messages containing links to phishing websites. The victim assumes the message is trustworthy and opens the link in their browser. Once the link is open the attacker can steal the victim’s personal data, credentials and bank information, then use it to perform activities like theft and blackmail.The picture below shows the interactions between an attacker and a victim when the
Phishing attack takes place.
Let’s now look at an example of a phishing attack initiated using e-mail. The e-mail offers the reader the chance to win a huge sum by taking part in a competition.
As you can see in the image above, there are plenty of indicators to assume the e-mail is suspicious and could lead to a phishing attack. A few immediate questions to ask are:
You should be treating an e-mail or message like this with utmost care and ensure you don’t fall into the trap of the attacker.
We can try preventing the phishing attack using the following steps:
security field say No encryption? That’s a big reason to ignore the e-mail.https? If not, don’t click.To pull off a
Clickjacking, an attacker tricks a victim to click on a page element that is not visible to them. The victim may be tricked into downloading a piece of malware, carrying out unwanted transactions and many other dangerous activities.First, the attacker sends an e-mail with the offer that embeds a link to a target website. The offer may have an awesome trip to Miami or the Caribbean, for example. But the attacker has embedded a hidden UI element (perhaps an iFrame) that can initiate a transfer of $2,000 to their bank account. The victim clicks the link and loads the offer form into the browser. The clickjacking happens when the victim clicks on the hidden UI element; the transfer is made to the attacker’s bank account without the victim even being aware of it.
The picture below shows the interactions between an attacker and a victim when the
Clickjacking attack takes place.
Most
clickjacking attempts take place using an iFrame and we can protect our apps using the X-Frame-Options response header. X-Frame-Options indicate whether the browser should allow a page to be rendered within the <iframe> tag. There are three possible values for the X-Frame-Options header:Taking these precautions on the server side will reduce the chances of clickjacking. On the client side, you can install extensions to the browser to test its vulnerability.
The
Cross-Site Request[Forgery](<http://forgery.is>), or CSRF, is a particularly innovative and challenging form of attack whereby the attacker tricks the victim into performing unwanted actions on the web application that they are currently authenticated into.The attacker creates a fake request for money (say, $2,000) and embeds it in a message such as an e-mail, which is then sent to the victim. The victim clicks on the link and issues the request to the bank unknowingly. The bank receives the request. There is no way for the bank to know that the request is the result of a forgery, so they release the money and the attacker receives it.
The picture below shows the interactions between an attacker and a victim when the CSRF attack takes place.
SameSite cookie helps the browser decide whether to send cookies with the cross-site requests. The possible values are strict, lax and none.Please consult the CSRF Protection Cheat Sheet for more details.
The final web application attack we will discuss in this article is the
Path (or Directory) Traversal Attack. This form of attack allows the attacker to read any files from the server that is running the application, opening up myriad possibilities to discover passwords, banking details, secret information and various other data.An attacker can access an allowed path to load an image and render it in the browser. The website is vulnerable to the
Path (or Directory) Traversal attack and allows the attacker to browse to the /etc/passwd file. On a unix-based operating system, a special file contains the details of registered users, so the attacker can steal important data from the server.The picture below shows the interactions between an attacker and a victim when the
Path(or Directory) Traversal attack takes place.
base directory . We should use this path to the file-system API to canonicalize the path and verify that this path starts with the expected base directory. Here is a code snippet that will do this for us.
File file = new File(BASE_DIRECTORY, input);
if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) {
// do something…
}I hope you found the article insightful! We have covered the core details of five major web security attacks. Your web application is now significantly protected from all of them. Here are a few links you may find relevant to the topics discussed in this article:
We will learn about another set of web security attacks in a future article. So stay tuned!