The text covers three cybersecurity topics: ARP spoofing, DDoS attacks, and JWT vulnerabilities. ARP spoofing exploits the ARP protocol's lack of authentication to send fake ARP replies, enabling traffic interception and man-in-the-middle attacks. DDoS attacks overwhelm targets with traffic from a botnet, causing service disruption. JWT vulnerabilities arise from weak signature algorithms, allowing token manipulation for privilege escalation or injection attacks. Defenses include static ARP tables, firewalls, VPNs, DDoS protection services, and secure JWT practices like HttpOnly cookies and regular key rotation.
1. ARP Spoofing
1.1 Introduction to ARP (Address Resolution Protocol)
The Address Resolution Protocol is a TCP/IP protocol used to obtain a physical address from an IP address. When a host sends information, it broadcasts an ARP request containing the target IP address to all hosts on the local network and receives a reply to determine the target's physical address. Once the reply is received, the IP-to-physical-address mapping is stored in the host's ARP cache for a certain period, so future requests can query the cache directly to conserve resources.
ARP is built on the premise of mutual trust among hosts on a network. Any host on a LAN can freely send ARP reply messages, and other hosts will accept and cache these replies without verifying their authenticity.
This allows an attacker to send forged ARP reply packets to a target host, causing its outgoing traffic to never reach the intended destination or to arrive at the wrong host — this is what constitutes an ARP spoofing attack.
The ARP command can be used to query IP-to-MAC address mappings in the local ARP cache, as well as to add or remove static mappings, among other operations.
1.2 Vulnerability Details
ARP-based network communication relies on both parties knowing each other's MAC address in order to communicate properly.
ARP spoofing exploits this mechanism by forging the source MAC and IP addresses and sending fake ARP reply packets to other hosts. When other devices on the network send data packets to the attacker-specified IP address, those packets are intercepted, leading to security issues such as traffic hijacking, eavesdropping, interception, and man-in-the-middle attacks.
A man-in-the-middle attack uses ARP spoofing to trick the victim host into sending traffic to the attacker's machine, which then forwards the traffic onward, thereby gaining access to the information exchanged between the victim host and other websites.
1.3 Exploitation
fping -asg 102.168.10.0/24Scans hosts in a specified network segment to identify attack targets.
-i specifies the network interface, i.e., which NIC to use for the ARP attack.
-t <victim IP>: specifies the victim host whose traffic will be redirected to the attacker's machine.
<gateway IP>: specifies the gateway IP to which the victim's traffic will be forwarded.
At this point, the victim will lose network connectivity because packet forwarding has not yet been configured. Enable traffic forwarding with the following command:
echo 1 > /proc/sys/net/ipv4/ip_forward
After that, you can monitor the victim host's network communications using Wireshark.
1.4 Defensive Measures
Use static ARP tables — manually add ARP entries on the network.
Use Port Security — bind network interfaces to specific MAC addresses to prevent attackers from plugging in unauthorized devices.
Use a VPN (Virtual Private Network) — encrypt data communications to prevent attackers from sniffing traffic.
Use an Internet firewall — restrict outbound network traffic to reduce the attacker's room for maneuver.
II. DDoS Attacks
2.1 What Is DDoS?
A DDoS attack is, at its core, about overwhelming a target server or network with a flood of requests, consuming its resources and rendering it unable to function properly.
2.2 How It Works
The attacker implants malicious code (e.g., a Trojan horse) into multiple computers or devices across the internet, exploiting software vulnerabilities, social engineering, and other techniques. These compromised machines are what we call a “botnet” or “zombies.”
The attacker then assembles these infected computers or devices into a “botnet,” sometimes also referred to as a “zombie army” or “zombie cluster.”
When the attacker decides to launch a DDoS assault, they command every machine in the botnet to bombard the target server or network with a torrent of data packets simultaneously. These packets may be specific types of requests — HTTP GET requests, for example — or simply packets stuffed with large amounts of junk data.
The target server or network gets swamped with requests from a multitude of different IP addresses and becomes unable to process them all, ultimately crashing the service.
This is made worse by the fact that the machines in the botnet are typically scattered across different geographic locations, each with a different IP address.
During a DDoS campaign, attackers will often cycle through a variety of attack vectors and techniques to maximize the disruptive impact.
2.3 Defensive Measures
The first consideration is whether traffic can be diverted — routing it through a third-party filtering provider such as Alibaba Cloud, Tencent Cloud, or Baidu Cloud, and then directing it back to your own infrastructure.
Use DDoS protection software or services: These typically detect and filter out malicious traffic sent by attackers, forwarding only legitimate packets to the target server or network.
Harden network security: Establish robust firewalls and Intrusion Detection Systems (IDS) to restrict unauthorized access and monitor the network for abnormal behavior.
Upgrade hardware, software, and firmware: Ensure your network and system hardware, software, and firmware are patched and running the latest versions.
Provision sufficient network bandwidth: Increasing available bandwidth helps disperse malicious traffic and mitigates the impact of DDoS attacks.
Enforce device access control on the network: Limit physical access and require stronger authentication to restrict rogue devices.
Provide employee security training: Ensure that management and staff understand common phishing, social engineering, and other types of cyberattacks, as well as how to avoid them.
III. JWT Vulnerabilities
3.1 Introduction to JWT
JWT (JSON Web Token) is a token used on the web for authenticating clients and servers, carrying the user's login information. When a user logs in, the server signs the JWT using an encryption algorithm; the frontend then sends the JWT containing user information (username, expiration, etc.) for the server to verify, and the token is stored locally on the frontend.
The token is Base64-encoded and consists of three parts, separated by dots (.).
This is the main body of the token. However, JWT defines only seven default parameters:
iss: JWT issuer
exp: Expiration time of the user's authentication (must be later than the issued-at time)
sub: Subject
aud: Audience (user)
nbf: Earliest time the JWT is valid
iat: JWT issued-at time
jti: JWT ID — a unique identifier
3.1.3 Signature
The signature is a hash-based digital signature (using a specified algorithm) applied to the two preceding parts, ensuring the data cannot be tampered with and providing integrity verification. It uses the Base64-encoded Header and Payload data. This part is stored on the server side.
During HTTP transmission, special characters in Base64 encoding — such as "=", "+", and "/" — can cause confusion during URL decoding. In Base64 URL encoding, "+" becomes "-", "/" becomes "_", and "=" is stripped out, thereby achieving URL-safe encoding.
3.1.4 Encryption Algorithms Supported by JWT
HMAC
HMAC encryption primarily uses a symmetric key, which is stored on the server side when the token is generated. HMAC is based on hash-based encryption algorithms — it combines a hash function with a secret key to produce a message digest that cannot be tampered with.
RSA
RSA encryption mainly uses a public/private key pair, where the public key encrypts information and the private key decrypts it.
In RSA mode, the public key can be used to encrypt the data inside a JWT, and the private key is then used to verify the JWT signature.
ECDSA
ECDSA is a signature algorithm that uses elliptic curves to produce digital signatures. Compared to RSA, ECDSA is better suited for performing digital signatures on mobile devices.
EdDSA
A digital signature algorithm based on elliptic-curve cryptography, widely used in high-security systems.
AES-GCM
A symmetric encryption algorithm that provides both integrity protection and confidentiality protection for data.
RSASSA-PSS
PBES2:
A password-based encryption scheme that uses a password together with a key derivation function to process data. PBES2 supports multiple encryption modes and hash algorithms.
A128KW, A192KW, A256KW
These are AES Key Wrap algorithms used to secure JWE (JSON Web Encryption) headers. They ensure integrity and confidentiality when transmitting encrypted JSON objects.
A128GCMKW, A192GCMKW, A256GCMKW
These are another set of AES Key Wrap algorithms for securing JWE (JSON Web Encryption) headers. They differ from the AES Key Wrap algorithms above in that they use a more secure and faster authenticated encryption block mode.
3.2 Signature Generation
Base64-encode the JSON data of the header and payload, producing two strings.
Join the two strings with a "." to form the complete unsigned JWT token.
Perform the digital signature computation on the token according to the chosen algorithm and key.
Append the signature to the JWT, forming a complete JWT token.
When sending a request, the sender places the JWT in the Authorization header of the HTTP request or in the request body (for POST, PUT, etc.), and declares the signature type used in the header.
After receiving the JWT, the recipient extracts the header, payload, and signature, then completes the verification process using the public key and the corresponding validation rules to determine whether the JWT is trustworthy.
3.3 Vulnerability Details
Strictly speaking, JWT itself has no vulnerabilities. The issues mainly relate to its signature algorithm. When the signature algorithm has weaknesses — for example, key leakage or keys that are easily brute-forced — an attacker may modify the claims (Payload) in the JWT token, re-encode it in Base64, and generate a new signature, leading to vulnerabilities such as privilege escalation and injection.
(The principle behind injection is that a JWT token essentially transmits JSON key-value pairs. When a user can manipulate those parameters and the server does not filter the input before passing it to SQL, an injection vulnerability may arise.)
(Privilege escalation is even easier to understand: simply modify the portion representing the user's permissions to a different role, such as administrator.)
3.4 Exploitation
3.4.1 Server Does Not Verify the Signature
Use BurpSuite to intercept the traffic, copy out the JWT token, and paste it into BurpSuite's JSON Web Token extension to decode it.
Modify parameters that may be vulnerable, such as those representing user permissions or the user ID.
Base64-encode the result, replace "+" with "-" and "/" with "_", remove the "=", assemble it into a new JWT token, replace the original token, and send.
3.4.2 Server Verifies the Signature
Capture the JWT token with BurpSuite, then use a tool such as jwtcrack to brute-force the key. The encryption method can be seen in the alg field of the header. This tool supports only HS256, HS384, and HS512; success depends on your wordlist.
Once the password is cracked, the exploitation method is the same as above — except that after Base64-encoding, you encrypt the result using the same algorithm and key to generate a signature, replace the original signature, and send.
3.5 Vulnerability Remediation
Store the JWT as an HttpOnly cookie to ensure that only the server can read the cookie.
Rotate JWT keys regularly to reduce the risk of compromise. In addition, do not store sensitive or private information inside the JWT; whenever possible, store only non-sensitive, basic information.
1. ARP Spoofing
1.1 Introduction to ARP (Address Resolution Protocol)
The Address Resolution Protocol is a TCP/IP protocol used to obtain a physical address from an IP address. When a host sends information, it broadcasts an ARP request containing the target IP address to all hosts on the local network and receives a reply to determine the target's physical address. Once the reply is received, the IP-to-physical-address mapping is stored in the host's ARP cache for a certain period, so future requests can query the cache directly to conserve resources.
ARP is built on the premise of mutual trust among hosts on a network. Any host on a LAN can freely send ARP reply messages, and other hosts will accept and cache these replies without verifying their authenticity.
This allows an attacker to send forged ARP reply packets to a target host, causing its outgoing traffic to never reach the intended destination or to arrive at the wrong host — this is what constitutes an ARP spoofing attack.
The ARP command can be used to query IP-to-MAC address mappings in the local ARP cache, as well as to add or remove static mappings, among other operations.
1.2 Vulnerability Details
ARP-based network communication relies on both parties knowing each other's MAC address in order to communicate properly.
ARP spoofing exploits this mechanism by forging the source MAC and IP addresses and sending fake ARP reply packets to other hosts. When other devices on the network send data packets to the attacker-specified IP address, those packets are intercepted, leading to security issues such as traffic hijacking, eavesdropping, interception, and man-in-the-middle attacks.
A man-in-the-middle attack uses ARP spoofing to trick the victim host into sending traffic to the attacker's machine, which then forwards the traffic onward, thereby gaining access to the information exchanged between the victim host and other websites.
1.3 Exploitation
1.4 Defensive Measures
II. DDoS Attacks
2.1 What Is DDoS?
A DDoS attack is, at its core, about overwhelming a target server or network with a flood of requests, consuming its resources and rendering it unable to function properly.
2.2 How It Works
2.3 Defensive Measures
The first consideration is whether traffic can be diverted — routing it through a third-party filtering provider such as Alibaba Cloud, Tencent Cloud, or Baidu Cloud, and then directing it back to your own infrastructure.
III. JWT Vulnerabilities
3.1 Introduction to JWT
JWT (JSON Web Token) is a token used on the web for authenticating clients and servers, carrying the user's login information. When a user logs in, the server signs the JWT using an encryption algorithm; the frontend then sends the JWT containing user information (username, expiration, etc.) for the server to verify, and the token is stored locally on the frontend.
The token is Base64-encoded and consists of three parts, separated by dots (.).
Example:
Encode:
Decode:
3.1.1 Header
3.1.2 Payload
This is the main body of the token. However, JWT defines only seven default parameters:
3.1.3 Signature
During HTTP transmission, special characters in Base64 encoding — such as "=", "+", and "/" — can cause confusion during URL decoding. In Base64 URL encoding, "+" becomes "-", "/" becomes "_", and "=" is stripped out, thereby achieving URL-safe encoding.
3.1.4 Encryption Algorithms Supported by JWT
3.2 Signature Generation
3.3 Vulnerability Details
Strictly speaking, JWT itself has no vulnerabilities. The issues mainly relate to its signature algorithm. When the signature algorithm has weaknesses — for example, key leakage or keys that are easily brute-forced — an attacker may modify the claims (Payload) in the JWT token, re-encode it in Base64, and generate a new signature, leading to vulnerabilities such as privilege escalation and injection.
(The principle behind injection is that a JWT token essentially transmits JSON key-value pairs. When a user can manipulate those parameters and the server does not filter the input before passing it to SQL, an injection vulnerability may arise.)
(Privilege escalation is even easier to understand: simply modify the portion representing the user's permissions to a different role, such as administrator.)
3.4 Exploitation
3.4.1 Server Does Not Verify the Signature
3.4.2 Server Verifies the Signature
3.5 Vulnerability Remediation