Website Hacking: XSS & SQL Injection
This thread covers two classic but still highly relevant web vulnerabilities:
Cross-Site Scripting (XSS) and SQL Injection (SQLi).
Despite being well-known, both issues are still widely present in real-world applications — especially in legacy code, custom CMS, admin panels, and poorly designed APIs.
1. Cross-Site Scripting (XSS)
XSS occurs when user-controlled input is:
- stored or reflected by the application
- not properly filtered or encoded
- executed by the victim’s browser
In short:
XSS is not about breaking the server — it’s about abusing trust on the client side.
2. Main types of XSS
- Reflected XSS — payload is reflected immediately in the response
- Stored XSS — payload is saved and executed later
- DOM-based XSS — execution happens via client-side JavaScript
Stored XSS is usually the most dangerous, since it affects every user who views the vulnerable page.
3. Stored XSS — practical concept
Typical scenario:
- comment system
- feedback form
- profile description
- support tickets
User input is saved and later rendered without proper encoding.
Example payload:
Code:
<script>alert('XSS')</script>If this executes when the page is viewed, the application is vulnerable to Stored XSS.
4. Why XSS matters
XSS is rarely limited to popups.
In real scenarios it is used for:
- session/token theft
- account takeover
- request forgery via victim’s browser
- page content manipulation
- pivoting to other vulnerabilities
XSS is often a starting point, not the final goal.
5. SQL Injection (SQLi)
SQL Injection happens when:
- user input is directly concatenated into SQL queries
- no parameterization is used
- the database executes unintended logic
In simple terms:
6. Typical SQLi entry points
SQL injection is often found in:
- login forms
- search fields
- filters and sorting parameters
- ID-based requests
- legacy admin panels
Example of risky logic:
Code:
SELECT * FROM users WHERE username = '$user' AND password = '$pass';If input is not handled correctly, the query logic can be altered.
7. What SQLi can lead to
Depending on the context and DB permissions:
- authentication bypass
- data extraction
- data modification
- user enumeration
- full database compromise
In many cases SQLi provides a direct path to complete backend control.
8. Why these bugs still exist
Common reasons:
- legacy codebases
- custom frameworks
- lack of input validation
- misunderstanding of trust boundaries
- copy-paste development
Many developers assume that:
They are usually wrong.
9. XSS + SQLi chaining
These vulnerabilities often complement each other.
Examples:
- XSS → steal session → access SQLi endpoint
- SQLi → inject XSS payload into stored content
- XSS → abuse authenticated functionality
Individually dangerous — combined, much worse.
10. Where people usually study these issues
To understand how these bugs look in practice, many use:
- OWASP Juice Shop
- DVWA
- WebGoat
- test CMS installations
- old or abandoned web projects
These environments show how small mistakes turn into serious issues.
11. Final notes
XSS and SQL Injection are not “beginner-only” bugs.
They survive because:
- they are easy to introduce
- hard to fully eliminate
- often underestimated
Understanding them properly gives a strong foundation for deeper web application analysis.
Last edited:
