What is a Web Attack?

Web attacks refer to malicious activities aimed at websites, network services, or web applications to steal data, disrupt services, deceive users, or other malicious purposes. In the digital age, cybersecurity has become an important issue that cannot be ignored by enterprises and individual users. As web attack methods continue to evolve, understanding and guarding against common web attacks has become particularly important. The ultimate goal is to maintain the smooth operation of web applications, enabling businesses and users to prevent network damage, data theft, and unethical competitive behavior.

What are the Common Means of Web Attacks?

Web applications may face a variety of attack types and methods, depending on the attacker's goals, the nature of the target organization's work, and specific security vulnerabilities in the web application. Common types of attacks include:

1. DDoS Attacks

Distributed Denial of Service (DDoS) is a common method of cyber attack. Its purpose is to overload the server with requests until it begins to slow down and eventually refuses to serve incoming requests for legitimate users. DDoS attacks can be classed in various ways, but it's common to group them into three types:

• 1. Volumetric Attack: Botnets send massive amounts of bogus traffic to a resource. This type of attack may use ping floods, spoofed-packet floods, or UDP floods. A volume-based attack is measured in bits per second (BPS).
• 2. Application Layer Attacks: Application layer attacks exploit common requests such as HTTP GET and HTTP POST. These attacks impact both server and network resources, so the same disruptive effect of other types of DDoS attacks can be achieved with less bandwidth. Distinguishing between legitimate and malicious traffic in this layer is difficult because the traffic is not spoofed and so it appears normal. An application layer attack is measured in requests per second (RPS).
• 3. Network Layer Attacks: Network-layer attacks, also known as protocol attacks, send large numbers of packets to a target. A network layer attack does not require an open Transmission Control Protocol (TCP) connection and does not target a specific port. A network layer attack is measured in packets per second (PPS). Examples of a network layer attack include:

1. Smurf Attack: Attempt to flood a server at the network level using Internet Control Message Protocol (ICMP) packets and exploiting IP vulnerabilities.
2. SYN Flood: Initiates a connection to a server without closing said connection, overwhelming servers as a result. This type of attack uses a vast amount of TCP handshake requests with poofed IP addresses.

While most attacks are volume-based, there are also “low and slow” DDoS attacks that elude detection by sending small, steady streams of requests that can degrade performance unobserved for long periods. Low and slow attacks target thread-based web servers and cause data to be transmitted to legitimate users very slowly but not quite slowly enough to cause a time-out error. Some tools used in low and slow attacks include Slowloris, R.U.D.Y., and Sockstress.

2. Cross-Site Request Forgery (CSRF)

 CSRF attacks exploit a website's trust in a user's browser. Attackers induce logged-in users to click a link or visit a page, which performs malicious actions on another logged-in website without the user's knowledge, using the user's identity.

In a successful CSRF attack, the attacker causes the victim user to act unintentionally. For example, this might be to change the email address on their account, to change their password, or to make a funds transfer. Depending on the nature of the action, the attacker might be able to gain full control over the user's account. If the compromised user has a privileged role within the application, then the attacker might be able to take full control of all the application's data and functionality. For a CSRF attack to be possible, three key conditions must be in place:

1. A relevant action: There is an action within the application that the attacker has a reason to induce. This might be a privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user's password).
2. Cookie-based session handling: Acting involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. There is no other mechanism in place for tracking sessions or validating user requests.
3. No unpredictable request parameters: The requests that act do not contain any parameters whose values the attacker cannot determine or guess. For example, when causing a user to change their password, the function is not vulnerable if an attacker needs to know the value of the existing password.

For example, suppose an application contains a function that lets the user change the email address on their account. When a user performs this action, they make an HTTP request like the following:

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=wiener@normal-user.com

This meets the conditions required for CSRF:

1. The action of changing the email address on a user's account is of interest to an attacker. Following this action, the attacker will typically be able to trigger a password reset and take full control of the user's account.
2. The application uses a session cookie to identify which user issued the request. There are no other tokens or mechanisms in place to track user sessions.
3. The attacker can easily determine the values of the request parameters that are needed to act.

With these conditions in place, the attacker can construct a web page containing the following HTML:

<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

If a victim user visits the attacker's web page, the following will happen:

1. The attacker's page will trigger an HTTP request to the vulnerable website.
2. If the user is logged in to the vulnerable website, their browser will automatically include their session cookie in the request (assuming SameSite cookies are not being used).
3. The vulnerable website will process the request in the normal way, treat it as having been made by the victim user, and change their email address.

 3. Cross-Site Scripting (XSS)

Cross-site scripting (also known as XSS) is a web security vulnerability that allows attackers to interfere with the interactions between users and a vulnerable application. It enables attackers to bypass the same-origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities typically allow attackers to masquerade as victim users, perform any actions that the user is capable of, and access any of the user's data. If the victim user has privileged access within the application, the attacker may be able to take complete control over all the application's functionality and data.

Cross-site scripting works by manipulating a vulnerable website so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application. There are three main types of XSS attacks. These are:

Reflected XSS: where the malicious script comes from the current HTTP request.

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Here is a simple example of a reflected XSS vulnerability:

https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>

The application doesn't perform any other processing of the data, so an attacker can easily construct an attack like this:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>

If the user visits the URL constructed by the attacker, then the attacker's script executes in the user's browser, in the context of that user's session with the application. At that point, the script can carry out any action, and retrieve any data, to which the user has access.

Stored XSS: where the malicious script comes from the website's database.

Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet data from network traffic.

Here is a simple example of a stored XSS vulnerability. A message board application lets users submit messages, which are displayed to other users:

<p>Hello, this is my message!</p>

The application doesn't perform any other processing of the data, so an attacker can easily send a message that attacks other users:

<p><script>/* Bad stuff here... */</script></p>

DOM-based XSS: where the vulnerability exists in client-side code rather than server-side code.

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:

var search = document.getElementById('search').value; var results = document.getElementById('results'); results.innerHTML = 'You searched for: ' + search;

If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.

4. SQL Injection Attack (SQLI)

SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. This can allow an attacker to view data that they are not normally able to retrieve. This might include data that belongs to other users, or any other data that the application can access. In many cases, an attacker can modify or delete this data, causing persistent changes to the application's content or behavior. In some situations, an attacker can escalate a SQL injection attack to compromise the underlying server or other back-end infrastructure. It can also enable them to perform denial-of-service attacks.

A successful SQL injection attack can result in unauthorized access to sensitive data, such as Passwords, Credit card details, and Personal user information. SQL injection attacks have been used in many high-profile data breaches over the years. These have caused reputational damage and regulatory fines. In some cases, an attacker can obtain a persistent backdoor into an organization's systems, leading to a long-term compromise that can go unnoticed for an extended period.

Basic SQL Injection: Suppose an application's login form validates users through the following SQL query:

SELECT * FROM users WHERE username = '$username' AND password = '$password';

If the application does not properly sanitize user input, an attacker could enter specially crafted input into the username or password fields, such as:

' OR '1'='1

This would turn the SQL query into:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '' OR '1'='1';

Because '1'='1' is always true, this query will return all users, potentially leading to unauthorized access.

Using comments to terminate the query: Attackers might use SQL comment symbols -- or /* */ to terminate part of the query's conditions, resulting in a query of all data. For example:

' OR 1=1 -- 

This would result in the password check part of the query being commented out, leading to the security check being bypassed.

Union Query Injection: Attackers can use the UNION operator to combine their malicious query with the original query, This could lead to the database returning additional sensitive information. For example:

' UNION SELECT * FROM users WHERE '1' = '1

Time Delay Injection: Attackers can test an application's vulnerability to SQL injection by inserting commands that cause the database to delay its response. For example, in MySQL:

' OR SLEEP(10) --

If the application is delayed for 10 seconds after executing this query, it may indicate that it is vulnerable to SQL injection attacks.

What are the Important Web Application Defense Strategies?

As mentioned above, web applications are attacked by various means and types. Therefore, defense strategies are also diverse and changing. With the continuous upgrading of system vulnerabilities and attack methods, the modern internet threat situation is very severe. Without certain "chip" security services that meet their specific business needs, any enterprise, unit, or individual is likely to be attacked.

1.  DDoS Protection: DDoS protection refers to the situation when services are overwhelmed by a surge in malicious traffic, causing the server to be overburdened. Based on real-time network traffic monitoring, traffic is immediately cleansed and filtered when a DDoS attack is identified. DDoS protection also provides preset defense strategies, based on attack profiles, behavior pattern analysis, AI intelligent recognition, and other protection algorithms to keep servers running stably.
2. Web Application Firewall (WAF): WAF filters and monitors the HTTP traffic between web applications and the internet to protect the security of web applications. It typically protects web applications from various forms of attacks, such as cross-site forgery, cross-site scripting (XSS), file inclusion, and SQL injection. WAF is important for web systems because new vulnerabilities appear too quickly and silently, and almost all systems themselves cannot automatically capture them.
3. Bot Management (BOT Management): It uses machine learning and other specialized detection methods to distinguish between automated traffic and human users, and prevents the former from accessing web applications.
4. Client-side Security: Check for new third-party JavaScript dependencies and changes to third-party code that our web application relies on, helping to catch malicious front-end vulnerabilities more quickly.
5. Attack Surface Management: Use attack surface management tools to map out and test web pages for vulnerabilities, identify potential security risks, and manually click to verify the presence of these risks.

How Does Tencent EdgeOne Prevent Web Attacks on Web Applications?

The Edge Security Acceleration Platform EO (Tencent EdgeOne, hereinafter referred to as EdgeOne) operates a global network spread across many cities. It is based on Tencent's edge computing nodes to provide acceleration and many of the security services listed above, including DDoS protection, web application firewall, bot management, and other security solutions. It safeguards industries such as e-commerce and retail, financial services, content information, and gaming, enhancing user experience.

EdgeOne can operate in any data center, thereby intercepting attacks at their source. Its functions complement the services and performance of websites, so using it can not only accelerate services but also protect them from more web attacks. In addition, all EdgeOne services are suitable for various web infrastructures and can usually be started with a simple configuration.

Learn more about acceleration services and access security services, or sign up for EdgeOne. We have now launched a free trial, click here or contact us for more information.