Web Application Hacking · Topic 5 of 8
Shared Environments, Database Connectivity and Web Client Attacks
How shared hosting, database connection weaknesses and attacks on the web client (XSS, CSRF, clickjacking) work, and the countermeasures CEH expects.
- 4 min
- Shared hosting risk is weak tenant separation. The fix is isolation.
- Connection string injection happens when the string is built from user input.
- Reflected, stored and DOM based are the three XSS types.
What it is
A web application depends on more than its own code. It may share a server with other sites, it talks to a database, and it runs scripts in the user's browser. Each of these connections can be attacked.
This page covers three areas: shared hosting and similar multi tenant platforms, the link between the application and its database, and attacks that target the person using the application.
How it works
Attack shared environments
In shared hosting, many customers' sites run on one server or one platform. A flaw in one tenant, or weak separation between tenants, can expose the others.
| Risk | Description |
|---|---|
| Cross tenant access | A compromised site reads files or data of a neighboring site |
| Shared service weakness | One database or runtime account used by many sites |
| Resource exhaustion | One site uses all CPU, memory or connections, so others fail |
| Symbolic link and file permission abuse | Following links to files owned by another tenant |
| Server wide compromise | Attacking the host after taking one site |
Countermeasures: isolate tenants with separate accounts, containers or virtual machines, apply file permissions strictly, set per tenant resource limits, use separate database accounts, patch the platform, and monitor for cross account access.
Attack database connectivity
Applications connect to a database with a connection string and credentials.
| Attack | Description |
|---|---|
| Connection string injection | When the string is built from user input, an attacker adds parameters to change the server, user or settings |
| Connection pool denial of service | Exhausting the pool of database connections so other users cannot connect |
| Hard coded or exposed credentials | Passwords in source code, configuration files or error messages |
| Data store weaknesses | Default accounts, remote access to the database port, weak encryption of stored data |
| Over privileged application account | An app account that can do far more than the application needs |
Countermeasures: build connection strings from fixed values, store credentials in a secrets store, encrypt them, give the application a low privilege account, limit database network access to the application server only, set pool limits and timeouts, and hide database errors from users.
Attack the web app client
Client side attacks aim at the user's browser, using the trust the browser has in the site.
| Attack | Description |
|---|---|
| Cross site scripting (XSS) | Attacker script runs in a trusted page. Reflected (in a link), stored (saved by the site), or DOM based (client script misuses data) |
| Cross site request forgery (CSRF) | The user's browser is made to send a request with the user's session |
| Clickjacking | A hidden or disguised frame makes the user click something unintended |
| Open redirect | The site forwards the user to an attacker chosen address, which makes phishing links look trusted |
| Cross origin resource sharing (CORS) misconfiguration | An overly open policy lets other sites read responses |
| Malicious or compromised third party scripts | Supply chain attacks on included JavaScript |
| Client side storage abuse | Sensitive data left in local storage or cookies |
XSS is the best known. Stored XSS is often the most serious type because it runs for every visitor without a crafted link. The impact includes stolen cookies, page defacement, keylogging and forced actions.
Defenses:
- XSS: encode output for its context, validate input with an allow list, use a Content Security Policy, set HttpOnly cookies and use frameworks that escape by default.
- CSRF: anti CSRF tokens, SameSite cookies and re-authentication for important actions.
- Clickjacking: the
X-Frame-Optionsheader or the CSPframe-ancestorsdirective. - Open redirects: only redirect to an allow list of destinations.
- Third party scripts: subresource integrity and a limited set of sources.
A worked example
A forum displays comments exactly as submitted. One comment contains script, and every reader's browser runs it. This is stored XSS. Encoding the output turns the script into harmless text, and a Content Security Policy blocks unexpected scripts if encoding is missed.
How the exam asks about this
- "Malicious script saved on the server and run for every visitor. Which XSS type?" -> Stored (persistent) XSS.
- "Which header prevents a page from being shown in a hidden frame?" ->
X-Frame-Options(or CSPframe-ancestors). - "Application account with excess rights on the database is a failure of which principle?" -> Least privilege.
What to remember for the exam
- Shared hosting risk is weak tenant separation. The fix is isolation.
- Connection string injection happens when the string is built from user input.
- Reflected, stored and DOM based are the three XSS types.
- CSRF abuses an existing session. XSS runs script in the page.
- Clickjacking is blocked by frame control headers.
An anti CSRF token does not stop XSS. If the attacker can run script on the page, the script can read the token.
Common mistakes
Confusing stored and reflected XSS. Stored is saved on the server. Reflected comes back from a crafted request.
Putting database credentials in source code. They end up in repositories and backups.
Thinking HttpOnly stops XSS. It only stops script reading that cookie.
Check yourself
Why is stored XSS often considered more dangerous than reflected XSS?
It affects every visitor without needing a crafted link.
How do you reduce the damage of a compromised application database account?
Give it the minimum privileges and restrict network access to the database.
What defends against clickjacking?
Frame control through
X-Frame-Optionsor the CSPframe-ancestorsdirective.
Topic 5 of 8 in Web Application Hacking
Test yourself on Web Application Hacking
The full EC-Council 312-50 question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by EC-Council. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.