Security Testing for Web Applications

Security Testing:-


Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request

1. Preventing CSRF requires three things:

1.1 Make sure your forms use POST(Already done)

1.2 Make sure your site is not vulnerable to XSS(Need to do)

1.3 Make your forms use a CSRF key(Already done)

I agree with the other two; this could be done on the browser-side, but would make impossible to perform authorized cross-site requests. Anyways, a CSRF protection layer could be added quite easily on the application side (and, maybe, even on the webserver-side, in order to avoid making changes to pre-existing applications) using something like this:

A cookie is set to a random value, known only by server (and, of course, the client receiving it, but not a 3rd party server)

Each POST form must contain a hidden field whose value must be the same of the cookie. If not, form submission must be prevented and a 403 page returned to the user.

CSRF, or Cross-Site Request Forgery, is a vulnerability very common in websites. In short, it means that if you have your site at, and an attacker at can display a form similar to one of your site’s, and make users on his site submit the forms on your site, possibly without their knowledge.

For example, if your blog comment box allows users to write JavaScript snippets that aren’t escaped in any way by the server and are ran, it’s most likely vulnerable to an XSS attack.


Convert special characters to HTML entities


The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe> or <object> . Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.

clickjacking attack:-

In some websites, we see some adds in iframe right.

An attacker can make use of iframe to trick the user to get into some malicious page.

design of the iframe may look genuine but he would be tricking the user to go into a malicious page or a site.

To check this issue


There are three possible directives for X-Frame-Options:-

X-Frame-Options: DENY

X-Frame-Options: SAMEORIGIN

X-Frame-Options: ALLOW-FROM

Content Security Policy:-

Is an W3C specification offering the possbility to instruct the client browser from which location and/or which type of resources are allowed to be loaded. To define a loading behavior, the CSP specification use “directive” where a directive defines a loading behavior for a target resource type.

Directives can be specified using HTTP response header (a server may send more than one CSP HTTP header field with a given resource representation and a server may send different CSP header field values with different representations of the same resource or with different resources) or HTML Meta tag, the HTTP headers below are defined by the specs:

  • Content-Security-Policy : Defined by W3C Specs as standard header, used by Chrome version 25 and later, Firefox version 23 and later, Opera version 19 and later.
  • X-Content-Security-Policy : Used by Firefox until version 23, and Internet Explorer version 10 (which partially implements Content Security Policy).
  • X-WebKit-CSP : Used by Chrome until version 25

More Details:-


Configure your web server to include an X-Frame-Options header. Consult Web references for more information about the possible values for this header:-

Note:- (Use case #3: SSL only)

/etc/nginx/sites-available/default:- Only Specified Domain and Sub Domain Restriction

server {

listen 80;

listen [::]:80;

#add_header Content-Security-Policy “default-src ‘self’; ‘’; ‘*’ ;”;

add_header Content-Security-Policy “default-src http:; script-src http: ‘unsafe-inline’; style-src http: ‘unsafe-inline'”;

add_header X-Content-Security-Policy “default-src http:; script-src http: ‘unsafe-inline’; style-src http: ‘unsafe-inline'”;

add_header X-WebKit-CSP “default-src http:; script-src http: ‘unsafe-inline’; style-src http: ‘unsafe-inline'”;


Only Specified Url Restriction:- sudo vim /etc/nginx/sites-available/default

server {

listen 80;

listen [::]:80;

#add_header Content-Security-Policy “default-src ‘self’; ‘’; ‘*’ ;”;

add_header Content-Security-Policy “connect-src http://*;;

add_header X-Content-Security-Policy “connect-src http://*;;

add_header X-WebKit-CSP “connect-src http://*;;

add_header X-XSS-Protection “1; mode=block”;

Apply the following changes to the web.config file to prevent ASP.NET version disclosure:-


Install thenginx-extraspackages like this:

install nginx-extras


http {


# Basic Settings


sendfile on;

tcp_nopush on;

tcp_nodelay on;

keepalive_timeout 65;

types_hash_max_size 2048;

server_tokens off;


more_clear_headers “Content-Type: “;

more_clear_headers “Accept-Ranges: “;

more_clear_headers “Content-Length: “;

more_clear_headers “server”;

more_clear_headers “ETag”;

more_clear_headers “Date”

more_clear_headers “Last-Modified”;

more_clear_headers “Connection”;

It’s recommended to disable OPTIONS Method on the web server:-


Web Application Security

Default nginx configuration is not perfect and can have many vulnerabilities that’s why we harden them to make it secure.

Disable unwanted HTTP methods

Most of the time, you need just GET, HEAD & POST HTTP request in your web application. Allowing TRACE or DELETE is risky as it can allow Cross-Site Tracking attack and potentially allow hacker to steal the cookie information.

  • Modify default.conf and add following under server block


if ($request_method !~ ^(GET|HEAD|POST)$ )
return 405;

Remove or restrict access to all configuration files acessible from internet:-

sudo chmod 400 Gruntfile.js

Restrict access to this directory or remove it from the website:-

drwxrwxr-x 4 freshgrcdomainfront freshgrcdomainfront 4096 Aug 9 10:52 src

sudo chmod 445 src/

dr-x—— 4 freshgrcdomainfront freshgrcdomainfront 4096 Aug 9 10:52 src

Investigate if it’s possible to reduce the response time for this page:-

GET /src/bower_components/angular-material/angular-material.js


One thought on “Security Testing for Web Applications

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s