Segfault ethical hacking week 10

SQL Injection & XSS (Cross-Site Scripting)

1. SQL Injection Points

SQL injection targets areas where SQL queries are executed on the web page.
To effectively perform SQLi, you must understand how parameters are used and how the backend fetches data from the database.

URL: boardRead.php?boardIdx=65

SELECT ... FROM ... WHERE idx = 65

Test injections:

• 65 AND 1=1

• 65' AND '1'='1

• 64+1

To bypass whitespace filters:

• Use comments: 65/**/AND/**/1=1

• Mix cases: 65 aNd 1=1

👉 The key is to deduce the structure of the SQL query on the server and craft your injection accordingly.

2. Types of SQL Injection

• Union-Based SQLi
   When query results are shown on the page.

• Error-Based SQLi
   When database error messages are displayed.

• Blind SQLi
   When there is no output but responses vary based on true/false conditions.
   This works in most scenarios, but is slower and harder to automate manually.

Defense Against SQL Injection

• Prepared Statements
   Compile SQL queries in advance using placeholders.
   Example:

SELECT ... FROM ... WHERE id = ?

• Whitelist Filtering
   Only allow known-safe input (e.g., for ORDER BY, table names, column names).

Notes for Penetration Testing

1. Avoid INSERT, DELETE, UPDATE queries – limit to non-destructive AND tests.

2. Avoid excessive use of comments (--, #) – may leave traces.

3. Never tamper with actual data (e.g., modifying user info).

Filter Evasion Techniques

• Whitespace Filtering: Replace spaces with comments.

  • Example: AND/**/1=1

• Bypass Parentheses Filtering: Alter syntax to work without brackets.

XSS (Cross-Site Scripting)

XSS is an attack that injects client-side scripts (typically JavaScript) into a web page to execute in another user's browser.

Purpose of XSS

Execute malicious scripts in the victim’s browser (not on the server).

What qualifies as client-side?

• HTML

• CSS

• JavaScript

Types of XSS Injection

1. Stored XSS

• The script is saved on the server and executed when the page is viewed.

• Common in:

  • User registration forms

  • Forum or bulletin board posts

Testing Stored XSS:

1. Check if input data is rendered back in the response.

2. Test with HTML special characters:

   • Example input: normaltic<""

3. Inject a basic script:

   
   <script>alert(1)</script>
   

Proof of Concept (PoC) options:

• alert(1)

• console.log()

• prompt(1)

• confirm('test')

Stored XSS is dangerous because other users viewing the data will unknowingly execute the injected script.

2. Reflected XSS

• The injected script is immediately reflected in the server's response via parameters.

• Common in:

  • Username availability checks

  • Search features (e.g., “No results found for ‘query’”)

Testing Reflected XSS:

1. Inject a payload in a GET parameter.

2. Confirm it appears in the response.

💡 Use:

<script>alert(1)</script>

Because this attack works via a malicious link, GET method must be used to share the attack vector.

Key Differences

Type	Storage Location	Execution Timing	Attack Vector
Stored	On the server	When page is viewed	Page with stored content
Reflected	In the URL/request	Immediate on request	Shared URL / link

XSS Defense Mechanisms

• Filter special characters like <, ", ', etc.

• Sanitize or encode user inputs in HTML context.

• Avoid inserting raw user input into scripts, attributes, or tags.

Why Is XSS Dangerous?

• Stored XSS: Scripts persist on the server, affecting all users who visit the infected page.

• Reflected XSS: Used for phishing-style attacks via URLs. Victims are tricked into clicking a link that executes JavaScript.

Always verify:

• Is the payload inserted in the request echoed back in the response?

• Is the page vulnerable to <script> injections?