Document on Secure Coding Guidelines for

Developers
Bank of Central Asia

Tata Consultancy Services

Training Material

28 Mar 2016
  Application Security Landscape

 Secure Code Review

The four code review steps are:

• Step 1: Identify security code review objectives. Establish goals and constraints for the review.

• Step 2: Perform a preliminary scan. Use static analysis to find an initial set of bugs and improve your
understanding of where bugs are most likely to be discovered during further review.

• Step 3: Review the code for security issues. Review the code thoroughly to find security
vulnerabilities that are common to many applications. You can use the results of step 2 to focus your
analysis.

• Step 4: Review for security issues unique to the architecture. Complete a final analysis that focuses
on bugs that relate to the unique architecture of your application. This step is most important if you
have implemented a custom security mechanism or any feature designed specifically to mitigate a
known security threat.
 Web Application Security Guidelines for Developers
Preventing SQL Injection:

Main reason behind sql injection: sql query acting as a mediator in between the application and
database is unable to differentiate the user submitted value and the actual query.

Inorder to prevent sql injection our query must have a capability to differentiate the user submitted
value and the actual query. This can be achieved by using Parametrized query or Stored Procedures
instead of ordinary statements.

SQL Query Vulnerable To SQL Injection:

 Usage Of Ordinary Statement making the
application vulnerable to SQL Injection

SQL Injection Prevention By Using Prepare Statement:

By using prepare statement as shown above

you can prevent your application from SQL
Injection attacks

Illegal Use Of Prepare Statement Makes Your Application Still Vulnerable To SQL Injection.

The below scenario depicts the illegal use of prepare statement.

Illegal Use Of Prepare Statement Making The

Application Vulnerable To SQL Injection

Preventing XSS Attacks:

 XSS – Cross Site Scripting:

3 Types Of XSS:

1. Stored or Persistent XSS – Values submitted by the user are directly stored in the database
without sanitizing the input and while retrieving the malicious input if displayed directly
without escaping HTML characters in the browser, then the retrieved script will get
executed making the application vulnerable to Stored XSS

2. Reflected XSS – The Classic example for this is search bar which displays the searched
text in the results page. When a user searches for a malicious input and if the input is not
HTML escaped then the browser will render and execute the script making the application
vulnerable to Reflected XSS

3. DOM Based XSS – If an application directly retrieves the data from the url and displays it
in the page then it makes the application vulnerable to DOM Based XSS

Prevention:

HTML characters must be encoded so that the browser will not render and execute the user submitted
HTML and script tags.

There is a library package available in OWASP for encoding HTML tags and it can be downloaded
from OWASP website. The name of the library file is ESAPI.jar

Once downloaded you have to use it in your application wherever it is required to escape html
characters.

Step 1:

Add the jar file in your WEB-INF library folder as shown in the image below
 ESAPI Jar File added inside \WEB-INF\lib\
folder

Step 2:

Import the library file in your java file inorder to make use of the functions present in the ESAPI jar

Now we have imported the ESAPI Jar to our

java file

Step 3:

Escape the html characters by using the encoder functions in ESAPI jar. Here am going to use
ESAPI.encoder().encodeForHTML(arg0) function for escaping the html characters submitted by the
user.
 Before processing the data here we have escaped
all the HTML characters using
ESAPI.encoder().encodeForHTML(arg0) which
makes our application free from XSS

Step 4:

If an application is vulnerable and multiple scripts have been injected in the database then while
retrieving and displaying the data makes the application vulnerable to XSS. Therefore JSP pages has to
encode the data and escape the HTML tags before displaying it to the user.

Adding escape functions in JSP Page:

Import the ESAPI package in JSP page

Escape the HTML characters if any and display

the occupation details
Preventing Session Hijacking:

Setting HttpOnly Tag To The Cookies:

By setting HttpOnly tag to the cookie it will ensure you that cookies cannot be retrieved using
Javascript. The below image shows how to set HttpOnly tag to the cookie

Cookie has to be added in the header inorder to set the

HttpOnly tag by using response.setHeader() and a keyword
called HttpOnly has to be added

Setting Secure Flag To The Cookies:

By setting secure flag to the cookies it will ensure that cookies will be transmitted only in a secure
channel which makes the user session free from Man In The Middle Attack. The below image shows
how to set secure flag to the cookie

Cookie has to be added in the header inorder to set the

HttpOnly tag by using response.setHeader() and a
keyword called secure has to be added

Preventing Session Hijacking & Session Fixation Attacks:

By using HttpSessions instead of cookies for authenticating the user, a developer can prevent his
application from session fixation attacks since the sessions are generated in the server side and cannot
be predicted by the attacker. Once the session is invalidated it will get deleted automatically in the
server side.

How to Prevent Web Browsers in caching your web pages?

Whenever the page is loaded in the web browser it should tell the browser don’t cache me. Inorder to
prevent the pages being cached by web browsers developer must set no-cache, no-pragma,
mustrevalidate in the response headers as shown below.
 By setting the response headers as shown above,
FQ_UserLoginProfile.jsp will not be cached by the web browser

Preventing Click Jacking Attacks:

This attack cannot be completely prevented and if the user is accessing the application using lower
version of browser example: IE 7 then the user is vulnerable to click jacking attack. Even a protected or
secure code will not help him in escaping from click jacking attacks. It is recommended to use recent
versions of browser inorder to stay secure from click jacking. By adding X-FRAME-OPTIONS in the
response headers your application pages cannot be loaded inside an iframe which makes your
application free from this attack.

X-FRAME-OPTIONS supports 3 options:

1. Allow
2. Same-Origin
3. Deny

Allow → Will allow the website to be framed by all the domains

Same-Origin → Will allow the website to be framed by the same domain

Deny → Will not allow the website to be framed inside an iframe

  Secure Coding Best Practices

CERT Secure Coding https://www.securecoding.cert.org/confluence/display/seccode/

Standards
Microsoft Secure http://msdn.microsoft.com/en-us/library/d55zzx87(v=VS.85).aspx
Coding Guidelines
OWASP Developer https://www.owasp.org/index.php/OWASP_Guide_Project
Guide
CWE/SANS Top 25 http://cwe.mitre.org/top25/