Web Application Security Testing

Web Application Security Testing

Typical Issues Discovered in an Application Test

• Cross-site scripting
• SQL injection
• Server misconfigurations
• Form/hidden field manipulation
• Command injection
• Cookie poisoning
• Well-known platform vulnerabilities
• Insecure use of cryptography

• Back doors and debug options
• Errors triggering sensitive information leak
• Broken ACLs/Weak passwords
• Weak session management
• Buffer overflows
• Forceful browsing
• CGI-BIN manipulation
• Risk reduction to zero day exploits

Below are key terms basically used in the security testing:

Vulnerability: Weakness or a loophole of the application, from where hackers can inject the virus or SQL injection.

There are different vulnerability like "High", "Medium" and "Low".

How to check the vulnerability test: Number of vulnerability scanners available through which user can check the web vulnerability.

(Acunetix Web Vulnerability Scanner, Rising Firewall, Window Vulnerability Scan)

URL Manipulation: It is also called URL rewriting, is the process of altering the parameters of the URL. Through this a hacker can get the additional information of user which are sending from client (browser) to server.

In a badly designed and developed web application, malicious users can modify things like prices in web carts, session tokens or values stored in cookies and even HTTP headers.

No data sent to the browser can be relied upon to stay the same unless cryptographically protected at the application layer. Cryptographic protection in the transport layer (SSL) in no way protects one from attacks like parameter manipulation in which data is mangled before it hits the wire. Parameter tampering can often be done with:

• Cookies

• Form Fields
• URL Query Strings
• HTTP Headers

SQL injection: This is the process through with a hacker can insert the sql query through user interface (with always true condition) that is executed by the server.

Example: SELECT * FROM Users WHERE User_Name = ‘” & strUserName & “‘ AND Password = ‘” & strPassword & “’;”

If the application has a log in page, it is possible that the application uses a dynamic SQL such as statement below. This statement is expected to return at least a single row with the user details from the Users table as the result set when there is a row with the user name and password entered in the SQL statement.

Or

SELECT * FROM Users WHERE Username='1' OR '1' = '1' AND Password='1' OR '1'='1';

After a short analysis we notice that the query returns a value (or a set of values) because the condition is always true (OR 1=1). In this way the system has authenticated the user without knowing the username and password.

To counter SQL injection attacks, you need to:

• Constrain and sanitize input data. Check for known good data by validating for type, length, format, and range.
• Use type-safe SQL parameters for data access. You can use these parameters with stored procedures or dynamically constructed SQL command strings. Parameter collections such asSqlParameterCollection provide type checking and length validation. If you use a parameters collection, input is treated as a literal value, and SQL Server does not treat it as executable code. An additional benefit of using a parameters collection is that you can enforce type and length checks. Values outside of the range trigger an exception. This is a good example of defense in depth.
• Use an account that has restricted permissions in the database. Ideally, you should only grant execute permissions to selected stored procedures in the database and provide no direct table access.
• Avoid disclosing database error information. In the event of database errors, make sure you do not disclose detailed error messages to the user.

Note   Conventional security measures, such as the use of Secure Socket Layer (SSL) and IP Security (IPSec), do not protect your application from SQL injection attacks.

XSS (Cross Site Scripting): When a user insert a HTML/Java script through the user interface of a web application and web application allows it to save or run on server side, then it is called XSS.

Exam:

1. http://host/a.php?variable=">
3. javascript:alert('XSS');">

How to Prevent it:

1. Tries the spacial characters as simple text.
2. Apply the filtering methods.

1. What is “Spoofing”?
   The creation of hoax look-alike websites or emails is called spoofing.
   
   
   Other user tecknikal terms in security Testing:
   Authentication - Testing the authentication schema means understanding how the authentication process works and using that information to circumvent the authentication mechanism. Basically, it allows a receiver to have confidence that information it receives originated from a specific known source.
   • Authorization - Determining that a requester is allowed to receive a service or perform an operation.
   • Confidentiality - A security measure which protects the disclosure of data or information to parties other than the intended.
   • Integrity – Whether the intended receiver receives the information or data which is not altered in transmission.
   • Non-repudiation - Interchange of authentication information with some form of provable time stamp e.g. with session id etc.
   
   
   Password Cracking: Web application should enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters).
   If username or password is stored in cookies without encrypting, attacker can use different methods to steal the cookies and then information stored in the cookies like username and password.
   
   
   
   
   Cookies Poisoning: Cookie Poisoning attacks involve the modification of the contents of a cookie (personal information stored in a Web user's computer) in order to bypass security mechanisms. Using cookie poisoning attacks, attackers can gain unauthorized information about another user and steal their identity.
   
   
   Developers should take a three-step approach to avoid cookies poisoning:
   
   
   • Do not store sensitive information in cookies
   • If sensitive information must be stored in cookies, make it extremely difficult for a user to successfully modify it
   • Validate all cookie values to ensure that they are well-formed and correct