1. Session Hijacking
1.1. The session hijacking is a type of web attack. It works based on the principle of computer sessions. The attack takes advantage of the active sessions. To know this in detail, we need to know what is a session. Let’s see what is a session and how the session works first.
1.2. How Does Session Hijacking Works?
1.2.1. Session Sniffing
1.2.2. As we’ve seen earlier, there is a string called tokens. This is the session id of a valid session. The first step by the attacker is getting this session id. The attacker uses a sniffer to get the session id. When the session id is captured, the attacker uses this session id to gain unauthorized access to the web server.
1.2.3. The Cross-Site Script Attack
1.2.4. The cross-site script attack is a way to get the session id with the helping of running malicious code or script from the client side. In this attack, the attacker executes malicious scripts, also known as malicious payloads into a legitimate website or web application. By using this attack, the attacker does not target a victim directly, but the attacker could exploit a vulnerability in a website that the victim would visit and use the website to deliver malicious script to the victim’s browser.
1.3. How to prevent the Session Hijacking?
1.3.1. The best way to prevent session hijacking is enabling the protection from the client side. It is recommended that taking preventive measures for the session hijacking on the client side. The users should have efficient antivirus, anti-malware software, and should keep the software up to date.
2. SQL Injection (SQLi)
2.1. SQL Injection (SQLi) refers to an injection attack wherein an attacker can execute malicious SQL statements (also commonly referred to as a malicious payload) that control a web application’s database server (also commonly referred to as a Relational Database Management System – RDBMS).
2.2. How SQL Injection works
2.2.1. In order to run malicious SQL queries against a database server, an attacker must first find an input within the web application that is included inside of an SQL query.
2.3. What’s the worst an attacker can do with SQL?
2.3.1. An attacker can use SQL Injection to bypass authentication or even impersonate specific users.
2.3.2. One of SQL’s primary functions is to select data based on a query and output the result of that query. An SQL Injection vulnerability could allow the complete disclosure of data residing on a database server.
2.3.3. Since web applications use SQL to alter data within a database, an attacker could use SQL Injection to alter data stored in a database. Altering data affects data integrity and could cause repudiation issues, for instance, issues such as voiding transactions, altering balances and other records.
2.3.4. SQL is used to delete records from a database. An attacker could use an SQL Injection vulnerability to delete data from a database. Even if an appropriate backup strategy is employed, deletion of data could affect an application’s availability until the database is restored.
2.3.5. Some database servers are configured (intentional or otherwise) to allow arbitrary execution of operating system commands on the database server. Given the right conditions, an attacker could use SQL Injection as the initial vector in an attack of an internal network that sits behind a firewall.
3. Cookie Poisoning
3.1. On the Web, cookie poisoning is the modification of a cookie (personal information in a Web user's computer) by an attacker to gain unauthorized information about the user for purposes such as identity theft.
3.2. To guard against cookie poisoning, Web sites that use them should protect cookies (through encryption, for example) before they are sent to a user's computer. Ingrian Networks' Active Application Security platform is one means of securing cookies.
4. Smurf
4.1. Smurf is a network layer distributed denial of service (DDoS) attack, named after the DDoS.Smurf malware that enables it execution.
4.1.1. ATTACK DESCRIPTION
4.1.1.1. In a standard scenario, host A sends an ICMP Echo (ping) request to host B, triggering an automatic response. The time it takes for a response to arrive is used as a measure of the virtual distance between the two hosts.
4.2. Smurf attacks are somewhat similar to ping floods, as both are carried out by sending a slews of ICMP Echo request packets.
4.3. A Smurf attack scenario can be broken down as follows:
4.3.1. Smurf malware is used to generate a fake Echo request containing a spoofed source IP, which is actually the target server address.
4.3.2. The request is sent to an intermediate IP broadcast network.
4.3.3. The request is transmitted to all of the network hosts on the network.
4.3.4. Each host sends an ICMP response to the spoofed source address.
4.3.5. With enough ICMP responses forwarded, the target server is brought down.
5. SYN Flood
5.1. TCP SYN flood (a.k.a. SYN flood) is a type of Distributed Denial of Service (DDoS) attack that exploits part of the normal TCP three-way handshake to consume resources on the targeted server and render it unresponsive.
5.1.1. ATTACK DESCRIPTION
5.1.1.1. Client requests connection by sending SYN (synchronize) message to the server.
5.1.1.2. Server acknowledges by sending SYN-ACK (synchronize-acknowledge) message back to the client.
5.1.1.3. Client responds with an ACK (acknowledge) message, and the connection is established.
5.2. Essentially, with SYN flood DDoS, the offender sends TCP connection requests faster than the targeted machine can process them, causing network saturation.
5.3. METHODS OF MITIGATION
5.3.1. Micro blocks—administrators can allocate a micro-record (as few as 16 bytes) in the server memory for each incoming SYN request instead of a complete connection object.
5.3.2. SYN cookies—using cryptographic hashing, the server sends its SYN-ACK response with a sequence number (seqno) that is constructed from the client IP address, port number, and possibly other unique identifying information. When the client responds, this hash is included in the ACK packet. The server verifies the ACK, and only then allocates memory for the connection.
5.3.3. RST cookies—for the first request from a given client, the server intentionally sends an invalid SYN-ACK. This should result in the client generating an RST packet, which tells the server something is wrong. If this is received, the server knows the request is legitimate, logs the client, and accepts subsequent incoming connections from it.
5.3.4. Stack tweaking—administrators can tweak TCP stacks to mitigate the effect of SYN floods. This can either involve reducing the timeout until a stack frees memory allocated to a connection, or selectively dropping incoming connections.
5.3.5. Obviously, all of the above mentioned methods rely on the target network’s ability to handle large-scale volumetric DDoS attacks, with traffic volumes measured in tens of Gigabits (and even hundreds of Gigabits) per second.