Source: TesterHome Community 

1. SQL Injection Attacks

SQL injection attacks occur when developers fail to perform strict security checks on parameters transmitted from the client to the server. When an SQL statement uses such parameters and executes via string concatenation, attackers can insert malicious SQL query statements into the parameters, forcing the server to execute them.

Potential harms

• Webpage and data tampering
• Theft of core data
• Database server compromise (turning it into a botnet node)

1.1 Testing Methods

On pages that require queries, input a correct query condition followed by simple SQL statements like and 1=1. Observe the response. If the returned result remains consistent with the result from the correct query condition alone, the application likely does not filter user input — suggesting a possible SQL injection vulnerability.

1.2 Prevention Methods

JDBC Queries. Use PreparedStatement. This improves query efficiency, and its set methods handle SQL injection issues automatically.

Hibernate Queries. Use named parameters (e.g., name:parameter) or methods like find(String queryString, Object value...) to avoid SQL injection.

Input Validation. Inspect SQL within query methods. Convert or filter out illegal characters that could be used for SQL injection.

Client-Side Restrictions. Use JavaScript on pages to prevent users from entering illegal characters. (Note: This serves user experience, not primary security control.)

Global Request Filter (Without Attachments). Implement a filter class inheriting HttpServletRequestWrapper and configure it in web.xml to intercept each request parameter and convert illegal characters.

Global Request Filter (With Attachments). Configure a class inheriting CommonsMultipartResolver for file uploads to process parameters.

Security Software. Deploy server and web application firewalls (e.g., “SafeDog”), and consider professional cloud security services.

2. CSRF (Cross-Site Request Forgery)

CSRF is a network attack where a malicious website tricks a user’s browser into executing unwanted actions on a trusted site where the user is authenticated — all without the user’s knowledge. Essentially, the attacker steals the user’s identity to send malicious requests that appear completely legitimate to the server.

Attack mechanism and process

• Step 1. User C opens a browser, visits Trusted Website A, and logs in with username and password.
• Step 2. Website A validates the user, generates a cookie, and sends it back to the browser. User C is now logged into Website A.
• Step 3. Before logging out of Website A, the user opens a new tab in the same browser and visits Malicious Website B.
• Step 4. Website B receives the request and returns malicious code, which includes a request targeting Website A.
• Step 5. The browser, following Website B’s request, automatically includes the cookie for Website A and sends a request to A without the user’s knowledge. Website A cannot tell the request originated from B and processes it with User C’s privileges, executing the malicious code from B.

2.1 Testing Methods

• Two-page test. Open two pages in the same browser. After the session or authentication for one page expires, check if actions on the other page can still be performed successfully.
• Referer removal test. Use a tool to send a request without the Referer header and verify the response message.

2.2 Defense Strategies

Referer Validation. Website A validates the Referer header for every request. If the Referer comes from A’s own domain, the request is likely legitimate. If it comes from another domain, it might be a CSRF attack and should be rejected. However, the Referer value is provided by the browser and can be spoofed or missing.

Token Validation. Add a unique, unpredictable token (e.g., synchronizer token) to each request and validate it on the server side. This is the most common and effective defense.

3. XSS (Cross-Site Scripting) Attacks

XSS occurs when a web application includes unvalidated or unescaped user input in its output pages, allowing attackers to inject malicious HTML or JavaScript code. This code executes in the context of another user’s browser. Unlike SQL injection (which targets the server), XSS targets other users of the application.

Potential impacts

• Cookie theft. Steal a user’s cookie to gain unauthorized access.
• Defacement. Modify webpage content.
• Phishing. Redirect users to malicious sites.
• Spam. Access user’s contact list to send mass messages.

3.1 Types of XSS

Stored (Persistent) XSS. Malicious script permanently stored on the server (e.g., in a database). Victims execute it when requesting stored information. Example: An attacker posts a comment containing malicious script. The server stores it. Every user viewing the comment executes the script.

Reflected (Non-Persistent) XSS. Malicious script reflected off the web server via a crafted link or form submission. The victim’s browser executes it when clicking the link. Example: A hacker posts a malicious link on a message board. The victim clicks it, sending the malicious script to the server, which reflects it back and executes it, sending the victim’s cookie to the hacker.

DOM-based XSS. The vulnerability exists in client-side JavaScript that processes user-controlled input unsafely (e.g., document.write, eval), altering the DOM maliciously.

3.2 Testing Methods

• Input test. Input alert(/123/) into a data input field or text box. If a dialog box pops up upon saving or submitting, an XSS vulnerability likely exists.
• URL parameter test. Modify a URL request parameter’s value to alert(/123/). If a dialog box pops up when the page loads, an XSS vulnerability likely exists.

3.3 Prevention Strategies

The core principle is to treat all user-provided content as unsafe. Filter or escape malicious code appropriately based on the output context (HTML attribute, JavaScript, CSS, etc.). Using a well-vetted library is highly recommended. For example, in Node.js projects, use the xss library.

4. URL Redirection Vulnerability (Open Redirect)

This vulnerability — also known as unvalidated redirects and forwards — occurs when a web application redirects users to a URL provided via untrusted input (e.g., a request parameter) without proper validation. Attackers can exploit this to redirect users from a legitimate trusted site to a malicious third-party site for phishing or other attacks.

4.1 Testing Methods

• Step 1. Use a proxy tool (e.g., Burp Suite) to capture the request.
• Step 2. Locate a 302 redirect response. Modify the target URL in the request and observe whether the application redirects to the modified, potentially malicious URL.

4.2 Bypass Techniques (For Testing and Understanding Defenses)

Note: Many modern applications use Referer validation or other checks, making simple bypasses ineffective.

• Using ?. Example: http://www.trusted.com/redirect?url=http://malicious.com?trusted.com
• Using / or \. Example: http://www.trusted.com/redirect?url=http://malicious.com/trusted.com
• Using @. Example: http://www.trusted.com/redirect?url=http://trusted.com@malicious.com (Firefox may show a warning)
• Using #. Example: http://www.trusted.com/redirect?url=http://malicious.com#trusted.com
• Exploiting weak whitelists. If the whitelist checks only whether the URL contains trusted.com (e.g., .trusted\.com.), an attacker could register a domain like malicioustrusted.com.

4.3 Prevention and Remediation Methods

Server-side mapping (best). If the destination URL is known beforehand, use an identifier (index) mapping to a pre-configured URL on the server.

Sign the redirect URL. If the URL is generated server-side, create a signature (e.g., HMAC) and validate it before performing the redirect.

Whitelist validation. If the URL must come from user input, strictly validate it against an approved list of domains or a safe URL pattern.

Input sanitization. Check for and remove control characters (e.g., URL-encoded for CRLF injection) from the redirect parameter.

Update dependencies. Keep all frameworks and libraries (e.g., Django, Nacos, Log4j2, nginx) up-to-date with the latest security patches.

5. Arbitrary File Upload Vulnerability

This critical vulnerability allows an attacker to upload a malicious executable file (e.g., Trojan, virus, script, WebShell) to the server. If the file can be executed or accessed, the attacker can gain control of the web server or application.

Potential harms

• Upload web script (.php, .asp, .jsp). The web server executes the script, leading to code execution on the server.
• Upload crossdomain.xml policy file. Control Flash’s behavior within the domain.
• Upload virus or Trojan. Trick users or admins into downloading and executing malware.
• Upload crafted image with embedded script. Phishing or client-side attacks.
• Upload WebShell. Complete control of the server.

5.1 Common Protection Methods (For Understanding Defense Mechanisms)

Client-side (JS) detection. Uses JavaScript to check file extension before upload. This is trivially bypassed (disable JS or intercept requests) and is not secure.

Server-side detection. Validates the file after receipt using MIME type, extension, and file content or magic bytes. This is reliable.

Blacklist. Denies specific file types (e.g., .php, .exe). Easy to bypass and weak.

Whitelist. Allows only specified types (e.g., .jpg, .png). This is the strongest approach.

5.2 Bypass Techniques (For Testing)

Bypassing client-side (JS) detection. Disable JavaScript in the browser, or use a proxy like Burp Suite to intercept the request and change the filename. Example: Change filename from malicious.jpg (to pass JS check) to malicious.php in the intercepted HTTP request.

Bypassing server-side MIME type detection. Intercept the request and modify the Content-Type header (e.g., from application/x-php to image/jpeg).

Bypassing extension detection.

• Case sensitivity. Use alternate case (e.g., .PhP, .AsP). Works only on very old web containers.
• Double nesting. If the server removes blacklisted substrings (e.g., removes php), use pphphp — after removal becomes php.
• Trailing spaces or dots. Add a space or dot (e.g., malicious.php ). Windows may trim automatically, but the server’s check might see a different extension.
• Null byte truncation. Use malicious.php.jpg. The server sees .jpg and allows upload, but the filesystem API stops at , saving the file as malicious.php. (Depends on older PHP versions.)
• Alternate extensions. Try .phtml, .php3, .php4, .php5, .inc, .asp instead of just .php.
• .htaccess (Apache). Upload a .htaccess file containing AddType application/x-httpd-php .jpg, then upload malicious.jpg containing PHP code (which will be executed as PHP).

5.3 Prevention Strategies

During system operation

• Set upload directory as non-executable. Configure the web server not to execute scripts in the upload directory — this is the most crucial defense.
• Validate file type. Use a whitelist for allowed MIME types and extensions. For images, re-encode or resize them to destroy embedded malicious code.
• Rename uploaded files. Use a random, unpredictable name (e.g., a UUID). Do not use the original path or name.
• Use a separate file server domain. Leverage the browser’s Same-Origin Policy to mitigate client-side attacks (e.g., crossdomain.xml, XSS via uploaded scripts).
• Deploy security devices. Use Web Application Firewalls (WAFs) or specialized security software to detect malicious upload attempts.

During system development

• Security awareness. Developers must have strong security awareness, especially when using languages like PHP.
• Strict validation. Implement validation on both client-side (for user experience) and server-side (for security). Server-side validation must use a whitelist and check for null bytes, content-type, file size, and file content.

During system maintenance

• Regular scanning. Proactively use security scanning tools to find and fix vulnerabilities.
• Log monitoring. Regularly review system and web server logs for signs of intrusion. Apply third-party security patches promptly.
• Remove unnecessary uploads. If file upload functionality is not essential, remove it. Configure server permissions strictly (e.g., upload directory as read-only with no execution).