ATTACK #1: SQL Injection

– Use prepared Statement with parameter markers (i.e. ?)
– Don’t use just prepared statement alone and avoid concatentating strings to form a query

Command Injection

– Exploit: Define linux commands into a string where that string is ultimately used inside an exec() function

Normal use:

exec(“cat log_” + $filebase + “.txt”);

Abuse case:

exec(“cat log_hits; rm -rf /; : .txt”); // This recursively deletes all files from the top

In windows,
– the Pipe command (|) can be used to append command-line functions
– dir command lists directories

– the Semicolon (;) can be used to append command-line functions
– the ls command lists directories

Solution #1: Input validation – Ignore illegal characters;
Solution #2: Processes should be limited with the least amount of permissions

XML Injection

Attackers can add and modified nodes on XML to manipulate application logic
Attackers can cause Denial of Service if they construct the fragments to be deeply nested

Solution: Use XML parsers

Document Type Definition Attack

– XML External Entities can be used to store strings of information that can be referenced like a variable during the parsing of XML
– They can also be used as a macrocommand to load files from a file system

– If attckers are able to construct or manipulate the XML, they can take advantage of the macro to load sensitive files from the local file system or other machines on the same network

Billion Laughs Attack

– Happens when attackers construct XML External Entities that reference other XML External Entities in an exponential manner. The result is that the process eats up too much memory causing the system to slow down when parsed (CPU 90%+)

– Solution: Strict validation before it gets parsed; Validate against DTD or XSD; Configure parser to limit entity resolution depth to as shallow as possible to prevent Billion Laughs

Overall General Mitigation Strategy Against Injection Attacks

1) Output Encoding – Do it right before displaying content to the user so that runnable code will be exposed and not executed
2) Input Validation – Ensure what public interfaces clients have access to are cross refrerenced against a white list and/or blacklist; use parameterized variables with prepared statements instead of concatentation
3) Logging and Auditing – The first two may not catch everything but at least there is a means of tracking attackers and assess damages when it does happen

ATTACK #2: Broken Authentication and Session Management

Sessions ID’s should be
– random
– non-colliding; unique so that a new session ID does not match an existing one and large enough so that it can be recreated through bruteforce
– Live as short as possible; server-side must expired the cookie, not the client

Exploit: Use browser plugins to view your local cookie; inspect the session ID; a bad session ID would be the concatentation of your IP and timestamp; Attackers could experiment by manipulating these values until it matches an active session ID of some other logged in user in the system.

How to test:

Have two users set up; Log in with the first and obtain the cookie; Have the second user login with the first person’s cookie appended

Check to see if the second user still maintains the first sessionID or has been issued a completely new one.

If it is the case it is the old one, then this is evidence of a session fixation issue; Log in as the first user and you will appear as the second one afterwards

Solution #1: Reduce time cookie is valid; client-side timeout; server-side timeout
solution #2: On the server-side, do not process session ID’s on GET/POST requests
Solution #3: When users authenticate successfully, issue new session ID’s
Solution #4: Only accept session ID’s that were created on the server-side
Solution #5: SSL/TLS to encypt data between client and server to prevent man in the middle
Solution #6: Map IP addresses to Session ID’s when possible
solution #7: Force re-authentication for highly critical operations (i.e. change password by supplying old, tranfering money, etc)
Solution #8: Use HTTPOnly flag to prevent XSS
Solution #9: Use random and long session IDs so that it cannot be easily guessed.

Other auth related problems

1) Username Enumeration – Attackers can construct dictionary to hammer out a valid username if the system responds whether the username exists or doest not
2) Weak password policies – Lack of these policies makes it easier to guess
3) Account Lockouts – Lack of lockouts allows attackers to continously attack
4) Password Reset Functionality – If the recovery questions are too easy, attackers can guess the responses.
5) Lack of auth – Some content on the website is able to be accessed without auth.

ATTACK #3: XSS (Cross-site Scripting)

Malcious code from another domain gets copied into a vulnerable domain which then gets executed by that web app or by the victims

Reflected Attack: User clicks on a malicious link which then the victim’s browser goes to that website, Javascript is run; Note the malcious code is not stored on the vulnerable website

The original intent was:

But the userNameParameter can be manipulated to do more:

Where request.getParamter("userName") would have been the following string:

mark' alert(document.cookie); var blah='

Solution #1: Don't reflect input created by users; it happens when state is stored in hidden fields; instead have state maintained on the server-side
Solution #2: Use both output encoding and input validation
Solution #3: Client-side and server-side validation
Solution #4: Logging and auditing for active and passive controls

ATTACK #4: Insecure Direct Object References

Happens when developesr expost a URL mapping to a resource in the web application; alternatively a name-value pair is explicit in the URL and attackers modified it to their advantage

%00 is a null byte; this causes execution to ignore anything else aftwards effectively making it the same as a semi colon

Network traffic can be sniffed to modifiy parameters on the request before it gets sent do the server; Attackers will put in garbage to see what will happen:

ERROR: /var/www/loan_docs/garbage_loan.docx file not found

This is open door for path manipulation attack

Use ../../../etc/shadow%00 to obtain a list of password hashes

How to Test:
- Look at all request parameters
- Don't rely on automated tools
- Code review
- Tamper with request parameters to see what happens and if it responds properly

Solution #1: Ensure server-sode process acting on user's behalf has the least amount of permissions to do it's job

Solution #2: chroot jail

Solution #3: Server-side generated resource mapping list; If clients misbehave and attempt to submit a mapping that does not exist, it could indicate there is an attack.

ATTACK #5: Security misconfiguration

When new securities advisories are release, it's just a matter of hours or days before an exploit is released. If an attacker is able to identify a vulnerable server, they will use tools like Metasploit Framwork, UI based exploits packages

Ensure after deployment that the server is properly configured to have it's Security settings configured to not have the default values

How to test: Use tools like Nessus to scan for network and system misconfiguration

Solution #1: Stay up to date with patches; attackers will reverse engineer patches to figure out what was fixed and then re-issue new exploits.

solution #2: Use system hardening tools like Bastille (*nix) and MS Baseline Security Analyzer (Windows)

ATTACK #6: Sensitive Data Exposure

C.I.A. of Information Security

Confidentiality - Verbose messages give too much insight about system
Integrity - Data that can be manipulated by attackers
Availability - Attackers can DOS to cause the applications to unusable

How to test for Insecure Crytographic Storage:
- Check code base for instance where cyptographic algorithms, libraries, and crypto APIs are used
- Ensure you are using the right algorithms for the right purposes
- Ensure data signatures are being used to validate the integrity of the data and the origin of the data
- Use for guidance on how long a crypto key needs to be
- If there are house-made algorithms, consider them weak and replace them with industry standard ones

Solution #1: Passwords need to be salt and hashed with the highest available cypto method available; Encypt other sensitive data

Solution #2: Use role-based access instead of user-based access to prevent hard coding against specific users

Solution #3: Use HTTPS using a cert from a trusted source

ATTACK #7: Missing Function Level Access Control

3 types of missing function level access control:

1) Forceful browsing: Attackers can guess resources on the web app and access them successfully if there is no authorization check

2) Vertical access: The lower privledged user is able to access the same resources a higher privledged user is allowed

3) Horizontal access: The attacker can access data/resources of other users with the same role

AuthN = Authentication; Validating if a user is in the system
AuthZ = Authorization; Validate if a user is allowed to access a resource

How to test against Forceful Browsing:
- With a site map attempt to navigate through the site as unauthenticated user

How to test against vertical access control:
- Look for operations that are only available to certain roles
- Log in as a different role and attenpt to access those operations

How to test against horizontal access control:
- Look for operations that specify id as a paremter and augment it to be another record belonging to another user

Solution #1: Any time a resource is requested by a client, it should automatically be routed to an authorization module to test if the logged in user is permitted to access the resource.

Solution #2: Admins should be able to manage entitlements based on roles

Solution #3: Default to no access

Solution #4: Don't depend on the client to block access to a control

ATTACK #8: CSRF (Cross Site Request Forgery)

- Attackers use


, JavaScript and hidden


are used to embed the trigger of an HTTP Request. The victim who is logged into the vulnerable website will unknowingly execute the request on a valid session with the server.

How to test: Use an HTTP Proxy to observe HTTP requests. If you can derrive a pattern to change the parameters to make the operation perform different than expected, you have an issue.

If you have no security ID or CSRF token on the request, then the web app is prone to CSRF. If there is a security ID or CSRF token on the request, modify it to something else and ensure that the server does not proccess the request.

This is a difficut issue to completely address if there exists at least one CSRF opening. Attackers will take advantage of this and use it to gain a valid security token to issue a CSRF attack

Solution #1: Prompt the user to re-enter their password for high-risk operations i.e. password change, transfering money, buying things

Solution #2: Use "out-of-band" verification process i.e. USB key with a hardware token, or a 1-time disposble password, or 2-step verification process via text message.

Solution #3: Use CAPTCHA challenges; downside on UX

ATTACK #9: Using Component with Known Vulnerabilities

Libraries/Components that you use don't necessarily publish their vulnerabilities. This is especially the case if it is open source.

Components often run with the same level of access as the application.

How to test:
- Perform inventory of all open source libraries used
- Static analysis tools can be used to automate this search

- Most components/libraries don't release patches; instead they fix it in the next release
- Update your dependencies to latest version

ATTACK #10: Unvalidated Redirects and Forwards

When we redirect or forward users without validating the destination, it provides attackers a door to trick users into visiting malicious websites

1) Present users with a login link in email or IM that has a redirect URL

2) The user will then be prompted to enter their credentials on legitimate site. Upon successful AuthN, they will be then redirected to whatever was defined on the redirect url

3) The user will be then shown on the exact same web that prompts them their username and password was incorrect. The user will then re-enter their credentials on the impersonating form. Upon succesfully submitting their credentials which are sent to the attacker, they will be then redirected to the original website.

4) The original website will not display username and password because they had already established a valid session on step 2)

How to test:
- Look for areas in the code that ask the user to input information
- Enter dummy urls that your application would never send a user i.e.
- If it succeeds, there is no url white list cross referencing or validationing happening

- Check destination prior to redirect or forward
- Implement proper access controls


Google+ Comments