As the internet and the World Wide Web got increasingly popular and powerful in the last 20 years, so did web applications. The landscape has evolved from simple CGI and scripting applications to powerful B2B and B2B applications, encompassing techniques such as Web 2.0, SaaS, cloud deployed applications and platforms such as mobile phones.
With this evolution also comes increasing risks posed by human and non-human actors to application users. Insecure software is already undermining the financial, healthcare, defense, energy, and other critical infrastructures of nations and businesses. The digital infrastructure has become increasingly complex and interconnected, resulting in increased difficulty of ensuring adequate application security.
Secure web applications, defined simply, means that the information exchange between authorized users and the system is handled with utmost care for security concerns. These concerns can be classified at high level in 3 categories:
Ensure only system permitted authorized users interact and exchange data.
Ensure that data is not compromised by users not authorized to use data.
Ensure systems are available for use when authorized users need them.
Web Application Security Architecture
The best system architecture designs and detailed design documents contain security discussions in each and every feature, how the risks are going to be mitigated, and what was actually done during coding. Security architecture starts on the day the business requirements are modeled, and are never finished until the last copy of your application is decommissioned.
This article aims at how one can build a rapid web application using Grails rapid application framework on the Java platform. Before we get into how Grails helps in developing a secure web application, let us briefly look at the details of common risks to web application security.
Web Application Security Threats
As per Open Web Application Security Project (OWASP) information, there are 10 most important security threats for web applications. This 2010 list enumerates the following most important risk categories:
Injection attacks, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an application backend as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.
Cross-site Scripting (XSS)
Broken Authentication and Session Management
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to steal passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.
Insecure Direct Object References
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
Cross-site Request Forgery (CSRF)
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.
Insecure cryptographic storage
Many web applications do not properly protect user sensitive data, such as credit cards, user PINs and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.
Failure to restrict secure URL access
Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.
Insufficient Transport Layer Protection
Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid security certificates, or do not use them correctly.
Invalid URL redirects and forwards
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
Grails Approach to Secure Application Development
As stated earlier in the first section, several non-trivial business web applications these days are developed using modern application frameworks designed for rapid application development using Agile methods and principles such as 'Do not repeat yourself' (DRY). These frameworks are available pretty much in all the widely used programming languages and platforms such as .NET, Java/JEE, PHP, Python, Ruby etc. Grails is one such platform designed for those principles using a modern approach to Model View Controller architecture.
Let us look at what Grails offer in securing and building a secure web application.
What does Grails framework provide out of the box?
Grails is no more or less secure than traditional web applications written using Java Servlets as controllers. However Java servlets (and hence Grails) are extremely secure and largely immune to common buffer overrun and malformed URL exploits due to the default security sandbox provisions of the JVM.
Web security problems typically occur due to developer naivety or mistakes, and there is a little Grails can do to avoid common mistakes and make writing secure applications easier to write.
Grails has a few built in safety mechanisms by default for the OWASP top 10 risks listed above. The support gets better with the maturity of the Grails platform and as adoption grows each day.
- All standard database access via GORM (Grails Object Relational Mapping) domain objects is automatically SQL escaped to prevent SQL injection attacks
- The default scaffolding HTML templates HTML all data fields when displayed.
- Grails link creating tags support such, g:link, g:form, g:createLink g:createLinkTo and others. All use appropriate escaping mechanisms to prevent code injection risk.
- Hibernate, which is the technology underlying GORM domain classes, automatically escapes data when committing to database so this is not an issue. However it is still possible to write bad dynamic HQL code that uses unchecked request parameters.
Currently Grails does not supply any implementation for this. There are multiple security plugins, including Spring Security, Shiro, and Authentication, and if your needs are very simple you can guard your application with Grails filters.
Cross-site Scripting Risk (XSS)
It is important that your application verifies as much as possible that incoming requests were originated from your application and not from another site. Ticketing and page flow systems can help. Grails has a plug in that supports Spring Web flow component for flow based web applications.
As a practice, one must also avoid the use of request parameters or data fields for determining the next URL to redirect the user to. If you use a successURL parameter, for example, to determine where to redirect a user to after a successful login, attackers can imitate your login procedure using your own site, and then redirect the user back to their own site once logged in, potentially allowing JS code to then exploit the logged-in account on the site.
Insecure URL access risk
This is where bad data is supplied such that when it is later used to create a link in a page, clicking it will not cause the expected behaviour, and may redirect to another site or alter request parameters. A safe bet is to assume that every unprotected URL is publicly accessible one way or another to help think about securing the URL access. HTML/URL injection is easily handled with codecs already built in Grails.
Denial of service
Load balancers, proxy servers and other appliances are more likely to be useful here, but there are also issues relating to excessive queries for example where a link is created by an attacker to set max=1000000 so that a query could exceed the memory limits of the server or slow the system down. The solution here is to always sanitize request parameters before passing them to dynamic finders or other GORM query methods:
Many applications use the last part of the URL as an "id" of some object to retrieve from GORM or elsewhere. Especially in the case of GORM these are easily guessable as they are typically sequential integers. Therefore you must assert that the requesting user is authenticated and authorized to view the details before returning the response to the user.
Other risks and application specific risks
For other security risks explicitly not handled by Grails, one can use OWASP enterprise security API for Java to handle them. Grails, being a Java compatible language, can easily interoperate with this API. For further reference, please refer the link https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
In this article, we have looked at the security aspects of web application, the typical risks a web application faces and high level overview of how a modern web development framework on the Java platform, GRAILS, helps you meet the goals of agile development without comprising web security.