WEB APPLICATION

SECURITY
By Vishal Tayade & Gauravi Wani
Threats
What is Web Application Security?

● Securing the “custom code” that drives a web application

● Securing libraries
● Securing backend systems
● Securing web and application servers
● Network Security Mostly Ignores the Contents of HTTP Traffic
● Firewalls, SSL, Intrusion Detection Systems, Operating System Hardening, Database Hardening
OWASP’s Top 10 List

A1. Cross-Site Scripting (XSS)

A2. Injections Flaws
A3. Malicious File Execution
A4. Insecure Direct Object Reference
A5. Cross Site Request Forgery (CSRF)
A6. Information Leakage & Improper Error Handling
A7. Broken Authentication & Session Management
A8. Insecure Cryptographic Storage
A9. Insecure Communications
A10. Failure to Restrict URL Access
A1. Cross-Site Scripting (XSS) Flaws

3 Categories of XSS attacks:

Stored - the injected code is permanently stored (in a database, message forum, visitor log, etc.)
Reflected - attacks that are reflected take some other route to the victim (through an e-mail message, or
bounced off from some other server)
DOM injection – Injected code manipulates sites javascript code or variables, rather than HTML objects.
Example Comment embedded with JavaScript comment=“Nice site!
A1. Cross-Site Scripting (XSS) - Protection

Protect your application from XSS attacks

● Filter output by converting text/data which might have dangerous
● Recommend filtering on input as much as possible. (some data may need to allow special
characters.)
A2. Injections Flaws

● Injection flaws, particularly SQL injection, are common in web applications. Injection occurs
when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s
hostile data tricks the interpreter into executing unintended commands or changing data.
● Some common types of command injection flaws include:
1. SQL injection (malicious calls to backend databases via SQL), using shell commands to run
external programs
2. Using system calls to in turn make calls to the operating system.
A2. Injections Flaws: Protection

● Use language specific libraries to perform the same functions as shell commands and system calls
● Check for existing reusable libraries to validate input, and safely perform system functions, or
develop your own.
● Perform design and code reviews on the reusable libraries to ensure security.
● Other common methods of protection include:
a. Use stored Procedures
b. Data validation (to ensure input isn't malicious code),
c. Run commands with very minimal privileges
d. If the application is compromised, the damage will be minimized.
A3. Malicious File Execution

● Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data,
resulting in devastating attacks, such as total server compromise. Malicious file execution attacks
affect PHP, XML and any framework which accepts filenames or files from users
● Applications which allow the user to provide a filename, or part of a filename are often vulnerable
if input is not carefully validated.
● Allowing the attacker to manipulate the filename may cause application to execute a system
program or external URL.
● Applications which allow file uploads have additional risks
A2. Injections Flaws: Protection

● Use language specific libraries to perform the same functions as shell commands and system calls
● Check for existing reusable libraries to validate input, and safely perform system functions, or
develop your own.
● Perform design and code reviews on the reusable libraries to ensure security.
A3. Malicious File Execution

● Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data,
resulting in devastating attacks, such as total server compromise.
● Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or
files from users.
A3. Malicious File Execution Protection

● Do not allow user input to be used for any part of a file or path name.
● Where user input must influence a file name or URL, use a fully enumerated list to positively
validate the value.
● File uploads have to be done VERY carefully.
1. Only allow uploads to a path outside of the webroot so it can not be executed
2. Validate the file name provided so that a directory path is not included.
3. Implement or enable sandbox or chroot controls which limit the applications access to files.
A4. Insecure Direct Object Reference

● A direct object reference occurs when a developer exposes a reference to an internal

implementation object, such as a file, directory, database record, or key, as a URL or form
parameter. Attackers can manipulate those references to access other objects without
authorization.
● Applications often expose internal objects, making them accessible via parameters.
● When those objects are exposed, the attacker may manipulate unauthorized objects, if proper
access controls are not in place.
A4. Insecure Direct Object Reference Protection

● Do not expose direct objects via parameters

● Use an indirect mapping which is simple to validate.
● Consider using a mapped numeric range, file=1 or 2 …
● Re-verify authorization at every reference.
A5. Cross Site Request Forgery (CSRF)

● A CSRF attack forces a logged-on victim’s browser to send a pre-authenticated request to a

vulnerable web application, which then forces the victim’s browser to perform a hostile action to
the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
● Applications are vulnerable if any of following:
1. Does not re-verify authorization of action
2. Default login/password will authorize action
3. Action will be authorized based only on credentials which are automatically submitted by
the browser such as session cookie, Kerberos token, basic authentication, or SSL certificate
etc.
A5. Cross Site Request Forgery (CSRF) Protection

● Eliminate any Cross Site Scripting vulnerabilities

1. Not all CSRF attacks require XSS
2. However XSS is a major channel for delivery of CSRF attacks
● Generate unique random tokens for each form or URL, which are not automatically transmitted by
the browser.
● Do not allow GET requests for sensitive actions.
● For sensitive actions, re-authenticate or digitally sign the transaction.
A6. Information Leakage & Improper Error Handling

● Applications can unintentionally leak information about their configuration, internal workings, or
violate privacy through a variety of application problems. Attackers use this weakness to steal
sensitive data or conduct more serious attacks.
Improper Error Handling: Protection

● Prevent display of detailed internal error messages including stack traces, messages with database
or table names, protocols, and other error codes. (This can provide attackers clues as to potential
flaws.)
● Good error handling systems should always enforce the security scheme in place while still being
able to handle any feasible input.
● Provide short error messages to the user while logging detailed error information to an internal
log file.
Information Leakage - Protections

● Ensure sensitive responses with multiple outcomes return identical results

● Save the the different responses and diff the html, the http headers & URL.
● Ensure error messages are returned in roughly the same time or consider imposing a random wait
time for all transactions to hide this detail from the attacker.
A7. Broken Authentication and Session Management

● Account credentials and session tokens are often not properly protected. Attackers compromise
passwords, keys, or authentication tokens to assume other users’ identities.
Session Management: Protection

● Use long complex random session ID that cannot be guessed.

● Protect the transmission and storage of the Session ID to prevent disclosure and hijacking.
● A URL query string should not be used for Session ID or any User/Session information
1. URL is stored in browser cache
2. Logged via Web proxies and stored in the proxy cache
Broken Account: Protection

● Password Change Controls - require users to provide both old and new passwords
● Forgotten Password Controls - if forgotten passwords are emailed to users, they should be required to
re-authenticate whenever they attempt to change their email address.
● Password Strength - require at least 7 characters, with letters, numbers, and special characters both
upper case and lower case.
● Password Expiration - Users must change passwords every 90 days, and administrators every 30 days.
● Password Storage - never store passwords in plain text. Passwords should always be stored in either
hashed (preferred) or encrypted form.
● Protecting Credentials in Transit - to prevent
● "man-in-the-middle" attacks the entire authenticated session / transaction should be encrypted SSLv3
or TLSv1 Man-in-the-middle attacks - are still possible with SSL if users disable or ignore warnings
about invalid SSL certificates.
● Replay attacks - Transformations such as hashing on the client side provide little protection as the
hashed version can simply be intercepted and retransmitted so that the actual plain text password is
not needed.
A8. Insecure Cryptographic Storage
● Web applications rarely use cryptographic functions properly to protect data and credentials.
Attackers use weakly protected data to conduct identity theft and other crimes, such as credit
card fraud.
● The majority of Web applications in use today need to store sensitive information (passwords,
credit card numbers, proprietary information, etc.) in a secure fashion.
● The use of encryption has become relatively easy for developers to incorporate.
● Proper utilization of cryptography, however, can remain elusive by developers overestimating the
protection provided by encryption, and underestimating the difficulties of proper implementation
and protecting the keys.
Insecure Cryptographic Storage: Protection

● Avoiding storing sensitive information when possible

● Use only approved standard algorithms
● Use platform specific approved storage mechanisms
● Ask, read and learn about coding Best Practices for your platform
● Careful review of all system designs
● Source code reviews
A9. Insecure Communications

● Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive
communications.
● Failure to encrypt network traffic leaves the information available to be sniffed from any
compromised system/device on the network.
● Switched networks do not provide adequate protection
Insecure Communications: Protection

● Use SSL/TLS for ALL connections that are authenticated or transmitting sensitive information
● Use SSL/TLS for mid-tier and internal network communications between Web Server,
Application and database.
● Configure Desktop Clients and Servers to ensure only SSLv3 and TLSv1 are used with strong
ciphers.
● Use only valid trusted SSL/TLS certificates and train users to expect valid certificates to prevent
Man-in-theMiddle attacks.
A10. Failure to Restrict URL Access

● Frequently, an application only protects sensitive functionality by preventing the display of links
or URLs to unauthorized users. Attackers can use this weakness to access and perform
unauthorized operations by accessing those URLs directly.
● When the application fails to restrict access to administrative URLs, the attacker can access
normally unauthorized areas by type in the URL’s into the browser.
A10. Failure to Restrict URL Access : Protection
● Create an application specific security policy during the requirements phase.
● Document user roles as well as what functions and content each role is authorized to access.
● Specifying access requirements up front allows simplification of the design
● If your access control is not simple it won't be secure.
Other Web Application Security Threats

● Unnecessary and Malicious Code

● Broken Thread Safety and Concurrent Programming
● Unauthorized Information Gathering
● Accountability Problems and Weak Logging
● Data Corruption
● Broken Caching, Pooling, and Reuse
Summary

● Application Security starts with the Architecture and Design

● Security can’t be added on later without re-designing and rewriting
● Custom code often introduces vulnerabilities
● Application vulnerabilities are NOT prevented by traditional security controls.
● Don’t invent your own security controls
● Design, Design, Design, code, test, test, test