SECURITY CHECKPOINTS FOR
ENTERPRISE APPLICATIONS ON THE
WEB
SHANAWAZ MANIYAR* M.Tech (Software Engineering) 4th semester Rastreeya Vidyalaya college of Engineering
Bangalore, Karnataka, India [email protected]
Mobile: +918722431118
SARAN GOVINDARAJAN Engineering Specialist,
Software AG Bangalore Technologies Pvt. Ltd. Bangalore, Karnataka, India
GEETHA V
Assistant Professor, Department of ISE Rastreeya Vidyalaya college of Engineering
Bangalore, Karnataka, India [email protected]
Abstract:
The HTTP protocol was originally developed for communication between scientists spread across different locations. Eventually it became so famous that all the computers using World Wide Web use the HTTP protocol. The purpose of HTTP protocol was just communication it was never designed for various other purposes like e-commerce. Today all the enterprises provide abundant resources on the web, any person with an internet connection and a web browser can access the enormous resources provided by the enterprises. The entire resources must be protected from malicious users while providing better services to legitimate users.
Today HTTP protocol is used for almost all our daily needs. But we are unaware of the fact that the HTTP protocol was never secure. HTTP is a stateless protocol with no secure architecture. Hence all the applications we use on HTTP should handle this security flaw. The solution to this problem is securing the applications which are to be hosted on the web.
Keywords: Security, Cross Site Scripting, Blind SQL Injections, Cross Site Request Forgery.
1. Introduction
With the advent of thin clients where entire processing happens at the server side, any person with an internet connection can access millions of web resources with just a browser Web applications allow visitors access to the most critical resources of a web site, the web server and the database server. A malicious user can harm an application if it is not secure on the web. In a survey by UK Security Breach Investigations Report it was found that 86% of all attacks, a weakness in the web application was exploited and the attackers were predominantly external (80%). Web applications are often riddled with vulnerabilities that are used by attackers to gain access to either the web server or the database server. From there any number of things can happen.
They can:
Insert spam links directing visitors to another site
Insert malicious code that installs itself onto a visitor’s computer Insert malicious code that steals session IDs (cookies)
Steal visitor information and browsing habits Steal account information
Steal information stored in the database Access restricted content
And much more…
The causes for all the above problems and their checkpoints for enterprise applications are as follows.
2. Security Holes and Checkpoints
2.1 Application Exceptions
Application Exceptions [1] are vulnerabilities where unexpected inputs can trigger inappropriate exceptions, or error responses disclosing implementation information, such as a stack trace, server information, application installation directory etc.
2.1.1 Checkpoints [2]
Ensure that the application input parameters are properly validated and checked for unexpected input, including null or empty values,
Ensure that your application architecture for handling error conditions is securely implemented. Standard application exception page that is displayed when errors occur
Return only generic error information to the client, not specific paths, directories, or the names of application components.
Minimize exposure by limiting the type of information that is disclosed when an error occurs, so that IP addresses, usernames, or passwords are not displayed when an error occurs.
Ensure that application errors are logged in an error log, but verify that sensitive information is not being logged as well. No private or confidential information should be logged.
2.2 SQL Injections
SQL Injection [3] is a vulnerability caused by a Web application sending user input into a SQL query without validation. It is a type of SQL Injection vulnerability, where an attacker infers information from differences in responses observed for different injections.
2.2.1 Checkpoints [4]
Define data types for each field Implement stringent "allow only good" filters reject bad input rather than attempting to escape or modify it; Implement stringent "known bad" filters.
2.2.2 Strong Design
Define an easy "secure" path to querying data
Use parameterized queries andstored procedures for interacting with the database Call stored procedures through a parameterized API
Validate all input through generic routines Use the principle of "least privilege"
Define several roles, one for each kind of query
2.2.3 Harden the Server
Run DB as a low-privilege user account
Remove unused stored procedures and functionality or restrict access to administrators. Change permissions and remove "public" access to system objects
Audit password strength for all user accounts Remove pre-authenticated linked servers Remove unused network protocols
2.2.4 Detection and Dissuasion
React to SQL injection attempts by: Logging the attempts
Sending email alerts Blocking the offending IP
Sending back intimidating error messages like:
"WARNING: Improper use of this application has been detected. A possible attack was identified - Legal actions will be taken."
2.3 Cookie Vulnerabilities[5]
A failure to specify proper attributes for cookies may result into stealing of cookie information through various attacks like Cross-Site Scripting (XSS) or a Man-In-The-Middle attack. The different types of cookies are:-
Insecure Cookies: For security of sensitive information, cookies must be marked as secure and only be transmitted if the communications channel with the host is a secure one. Servers should use SSL in this case.
HTTPOnly Cookies [6]: To avoid access and manipulation of cookies in the script, the HTTPOnly attribute should be set for the cookie.
Cacheable Cookies: You can disable caching of cookies on a page by setting the “Pragma: No-cache” and “Cache-control: No-cache, No-store”. To suppress caching of the Set-Cookie header only, the origin server should send ‘Cache-control: No-cache="set-cookie"’ in response header.
Persistent Cookies: Cookie which is used to store session-id information should not be persistent; expires or max age attribute for the cookie should be set accordingly, so that cookie information is valid only for the session.
2.3.1 Checkpoints
Different applications use different kinds of cookies hence, cookies should be set securely based on the type of application.
2.4 Cross-Site Scripting[7]
Cross-site Scripting vulnerabilities allow malicious scripts to execute in the context of a trusted session with a web site.
2.4.1 Checkpoints
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application’s input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:-
Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and url parameters.
Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.
If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.
Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.
2.5 Cross Site Request Forgery
Cross-site Request Forgery vulnerabilities allow unauthorized requests from a victim’s machine to improperly initiate transactions using an existing authenticated session.
2.5.1 Checkpoints
Design your application to carry a nonce along with all the requests. Make sure this token is unique to a session or changes upon every form submission.
Make use of OWASP CSRF-Guard [8] which enables web application to generate random token for every requests.
Add hash (session-id, function name, server-side secret) to URL and all forms.
2.6 Directory Browsing [9]
Getting information on the underlying directory structure gives an attacker useful information when planning attacks against your server or your application. Following checkpoints will help to prevent unintended information disclosure.
2.6.1 Checkpoints
Check the access permissions on the affected directories and configure them to prevent access. Configure the server to disallow directory listing
Examine your applications and if the directory list was obtained by exploiting a known bug in a third party application, contact the vendor or maintainer for a patch.
Review the code to prevent malformed strings or tricked Uri’s from bypassing the filters or input validation you are applying to directory GET requests.
2.7 Authentication Bypass [10]
This vulnerability attempts to bypass the login mechanism using SQL injection strings, URL manipulations and parameter additions.
2.7.1 Checkpoints
This vulnerability can be eliminated by fixing the SQL injection vulnerability in the application’s Authentication mechanism.
Keep up to date on patches and security fixes as they are released by the vendor or maintainer
Limit the types of characters and strings that can be passed as application parameters by configuring native application filters.
Avoid using external SQL interpreters.
Audit your applications frequently for points where HTML input can access interpreters.
Ensure proper input validation is performed wherever user supplied data can be supplied, regardless of the application’s relationship to a back-end database.
Avoid the use of dynamic SQL or PL/SQL and use bound variables whenever possible. Enforce strict limitations on the rights to database access.
Remove any sample applications or demo scripts that allow remote database queries. Monitor your production applications for the latest security vulnerabilities and bugs.
2.8 Clickjacking [11]
2.8.1 Checkpoints
It is possible to make use of a Web application as the target in Clickjacking by including pages from it in an <iframe> tag. You should use frame-Busting code to prevent your content from being framed or used in framesets.
2.9 Ineffective Session Termination
This is a vulnerability that permits unauthorized access to a session that should have normally been terminated.
2.9.1 Checkpoints
Always invalidate the session after logout both at the client and at the server side. Terminate the inactive session that has not been active over a reasonable time.
Security error or re-authentication should result in for requests that attempt to access a private page of the terminated session.
Session which is active for long time and reached the maximal allowed time must be re-authenticated.
2.10 Session ID Prediction [12]
Session ID Predictability is one of the most common vulnerabilities in HTTP session state management. Session IDs with insufficient randomness are vulnerable to brute force session guessing attacks.
2.10.1 Checkpoints
Encrypt network traffic using SSL. Doing so will prevent an attacker from obtaining session IDs through passive surveillance of your network. SSL does not make your site immune to session ID prediction, because it’s still possible for an attacker to steal cookies or authentication information from a victim’s browser.
Avoid sending session IDS in URLs to prevent the browser from caching the information.
The length of the session ID should be sufficiently larger with a large character set. It is also recommended to have a session ID with length not less than 32 characters which minimizes the predictability.
Avoid padding the session ID with easily predictable information. If you pad the session ID ensure the data is sufficiently random.
Encrypt your session IDs using a cryptographically strong algorithm, even if you are using SSL. Never rely on trivial obfuscation routines.
Take steps to prevent browser caching so that users cannot click the Back button to access the site with previous credentials.
Tear down inactive sessions and enforce strict time-out rules for logged in accounts. Session IDs should be generated by the server and never user supplied.
If you are using a third-party application that generates predictable session IDs, contact the vendor or maintainer for a security update. Ensure that your session IDs are not easily guessable by generating them from a large range and then encrypting the values.
3. Common Checkpoints
Use POST requests for all form submissions as GET requests get logged in the server log. Lockout the application in case of many failed login attempts.
Disable any Default/Guest accounts in your application if not needed.
Disable the potentially dangerous HTTP methods like PUT, DELETE, TRACE, TRACK, COPY, MOVE, LOCK, UNLOCK, SEARCH MKCOL PROPFIND, PROPPATCH,
Disable all the default web pages which leak out information to anonymous users.
4. Conclusion
The Security checkpoints on web applications will make the web applications secure and the risks associated with the applications will drastically decrease. Most of the web applications vulnerabilities can be avoided by proper filtering of the user input data and by proper output encoding. A majority of the vulnerabilities can be curbed by properly specifying the access control parameters. Secure programming techniques should be incorporated in order to avoid application flaws. The Security checkpoints for enterprise applications on the web, is a step in securing the enterprise applications.
References
[1] https://www.owasp.org/index.php/Top_10_2007-Information_Leakage_and_Improper_Error_Handling [2] https://www.owasp.org/index.php/Error_Handling,_Auditing_and_Logging
[3] www.sqlsecurity.com
[4] http://www.imperva.com/applicationdefense_center/white_papers/blind_sql_server_injection.html%23overview [5] http://www.owasp.org/documentation/topten.html
[6] http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/httponly_cookies.asp [7] https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
[8] https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project [9] https://www.owasp.org/index.php/Forced_browsing
[10] https://www.owasp.org/index.php/Testing_for_Bypassing_Authentication_Schema_%28OWASP-AT-005%29 [11] https://www.owasp.org/index.php/Clickjacking
