Software developers are critical for the success of any application. Achieving a secure software requires support and help for the software developers, by the organization they author code for. Different kinds of secure coding techniques need to be adopted and practised by software developers, as they author the code that constitutes a web application. All levels of web application, the business logic, the user interface, the database code, the controller and more – have to be build with security in mind. This is a tough task as most developers have not learned about crypto or secure coding in school. The frameworks and languages used by developers to build web applications often lack critical core controls or are not secure in some way. Usually there are inherent flaws in the design and requirements. It is also uncommon when organizations provide prescriptive requirements to developers, which can guide them towards a secure software.
This article aims to guide developers and other professionals towards a more secure web application software development. Following are some issues that developers need to be aware of. Presenting the OWASP secure coding checklist:
1. Parameterize Queries – One of the most dangerous web application risks is SQL Injection, and the reason for this is that they are easy to exploit, with easily available automated attack tools and it can create an impact that would be disastrous for your application.
In order to stop SQL injection, developers must avoid untrusted input from being translated as part of a SQL command. A programming technique known as Query Parameterization is the best way of doing this.
An example of Query Parameterization in Java is:
String newName = request.getParameter(“newName”);
String id = request.getParameter(“id”);
PreparedStatement pstmt = con.prepareStatement(“UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?”);
An example of Query Parameterization in PHP is:
$email = $_REQUEST[‘email’];
$id = $_REQUEST[‘id’];
$stmt = $dbh->prepare(”update users set email=:new_email where id=:user_id”);
2. Encode Data – Encoding is another dynamic mechanism that can protect an application against number of attacks, especially injection attacks. Basically, encoding requires translating special characters into something identical, which is no longer important to the target interpreter. Encoding that can stop different kinds of injection include Windows encoding, Unix encoding, XML encoding and LDAP encoding. Another example is output encoding, which is necessary to avoid Cross Site Scripting.
XSS attacks that are executed in the user’s browser can have a variety of effects.
XSS site defacement:
(script)document.body.innerHTML(“Jim was here”);(/script)
XSS session theft:
var img = new Image();
3. Validate All Inputs – It is important to treat all inputs that are coming from outside of the application as untrustworthy (for example, from mobile clients or browsers and from outside files or systems). For web applications it includes cookies, HTTP headers, POST parameters and GET, any or all of this information can be used by an attacker.
One of the ways of building a secure web application is to curb the input that a user is allowed to submit to the web application. Limiting user input is a method called ‘input validation’. Input validation can be added in web applications, using regular expressions. They are a type of code syntax that help if certain patterns matches the string.
By user input validation, every piece of data can be validated with a set of characters and they can meet the expectations for data length. This makes attacking the web application even more difficult.
4. Implementing Appropriate Access Controls
Access Control or Authorization is the process, which requires accessing a particular feature or resource that can be granted or denied. However, it should be noted that authorization is not equal to verifying identity or authentication.
Access control designs heavy security control and it can be complex. They should be considered in the initial stages of application development. After choosing a particular access control design pattern, it becomes difficult and time consuming to re-engineer access control in the application with a new pattern. Following points have to be considered for Access Control:
• All requests should be forced to go through access control checks
• They should be denied by default
• Hard-coded policy based access control checks should be avoided
• Code to the activity
• Access control should be driven by server-side trusted data
5. Identity and Authentication Controls Should Be Established
The process of verifying an entity or individual to check if it is what it claims to be, is called ‘Authentication’. It is commonly done by submitting an ID or user name and some other private information, which only a given user would know.
The process in which a server maintains the state of the entity, with which it is interacting is called Session Management. It is required for a server to remember how to react towards subsequent requests through a transaction.