Penetration Testing Training

Web Application Penetration Testing – Part 4

This blog post series will be covering the topic of performing Web Application Penetration Tests. Web Application Penetration Testing Part 1 and Part 2 focused on gathering information about the web server, the web application and its framework. Part 3 explained and demonstrated the Dirbusting technique.

In this fourth part of our series we will focus on Web Proxies and how to use one, how to test for HTTP methods, the HTTP Strict Transport Security header and a few more other Secure HTTP headers recommended by OWASP that you should check for their presence.

Proxy

In computer networking, a proxy server is a server application or appliance that acts as an intermediary for requests from clients seeking resources from servers that provide those resources. A proxy server thus functions on behalf of the client when requesting service, potentially masking the true origin of the request to the resource server. Instead of connecting directly to a server that can fulfill a requested resource, such as a file or web page for example, the client directs the request to the proxy server, which evaluates the request and performs the required network transactions. This serves as a method to simplify or control the complexity of the request, or provide additional benefits such as load balancing, privacy, or security. Proxies were devised to add structure and encapsulation to distributed systems.

https://en.wikipedia.org/wiki/Proxy_server

Using a Web Proxy, we can intercept and process/modify any requests sent to the Web Application Server.

Burp Proxy

The Proxy tool gives you a direct view into how your target application works “under the hood”. It operates as a web proxy server, and sits as a man-in-the-middle between your browser and destination web servers. This lets you intercept, inspect and modify the raw traffic passing in both directions. Intercept tab dispays individual HTTP requests and responses that have been intercepted by Burp Proxy for review and modification. This feature is a key part of Burp’s user-driven workflow. Manually reviewing intercepted messages is often key to understanding the application’s attack surface in detail. Modifying request parameters often allows you to quickly identify common security vulnerabilities. Intercepted requests and responses are displayed in an HTTP message editor, which contains numerous features designed to help you quickly analyze and manipulate the messages.

https://portswigger.net/support/using-burp-proxy

HTTP methods revisited

Some of the HTTP methods can potentially pose a security risk for a web application, as they allow an attacker to modify the files stored on the web server and, in some scenarios, steal the credentials of legitimate users.

PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files, or by simply using the victim’s server as a file repository.

DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.

CONNECT: This method could allow a client to use the web server as a proxy.

TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman.

If an application needs one or more of these methods, such as REST Web Services (which may require PUT or DELETE), it is important to check that their usage is properly limited to trusted users and safe conditions.

https://www.owasp.org/images/1/19/OTGv4.pdf
https://wiki.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)

OWASP Secure HTTP Headers

The OWASP Secure Headers Project describes HTTP response headers that your application can use to increase the security of your application. Once set, these HTTP response headers can restrict modern browsers from running into easily preventable vulnerabilities.

  • HTTP Strict Transport Security (HSTS)
  • Public Key Pinning Extension for HTTP (HPKP)
  • X-Frame-Options
  • X-XSS-Protection
  • X-Content-Type-Options
  • Content-Security-Policy
  • X-Permitted-Cross-Domain-Policies
  • Referrer-Policy
  • Expect-CT
  • Feature-Policy

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is a web security policy mechanism which helps to protect websites against protocol downgrade attacks and cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.

Public Key Pinning Extension for HTTP (HPKP)

HTTP Public Key Pinning (HPKP) is a security mechanism which allows HTTPS websites to resist impersonation by attackers using mis-issued or otherwise fraudulent certificates. The HTTPS web server serves a list of public key hashes, and on subsequent connections clients expect that server to use one or more of those public keys in its certificate chain.

X-Frame-Options

X-Frame-Options response header improve the protection of web applications against Clickjacking. It declares a policy communicated from a host to the client browser on whether the browser must not display the transmitted content in frames of other web pages.

X-XSS-Protection

This header enables the Cross-site scripting (XSS) filter in your browser.

X-Content-Type-Options

Setting this header will prevent the browser from interpreting files as something else than declared by the content type in the HTTP headers.

Content-Security-Policy

A Content Security Policy (CSP) requires careful tuning and precise definition of the policy. If enabled, CSP has significant impact on the way browsers render pages (e.g., inline JavaScript disabled by default and must be explicitly allowed in policy). CSP prevents a wide range of attacks, including Cross-site scripting and other cross-site injections.

X-Permitted-Cross-Domain-Policies

A cross-domain policy file is an XML document that grants a web client, such as Adobe Flash Player or Adobe Acrobat (though not necessarily limited to these), permission to handle data across domains. When clients request content hosted on a particular source domain and that content make requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction. Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the X-Permitted-Cross-Domain-Policies HTTP response header.

Referrer-Policy

The Referrer-Policy HTTP header governs which referrer information, sent in the Referer header, should be included with requests made.

Expect-CT

The Expect-CT header is used by a server to indicate that browsers should evaluate connections to the host emitting the header for Certificate Transparency compliance.

Feature-Policy

The Feature-Policy header allows developers to selectively enable and disable use of various browser features and APIs.

https://owasp.org/www-project-secure-headers

Curl

Curl is a tool to transfer data from or to a server, using one of the supported protocols (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP). The command is designed to work without user interaction. curl offers a busload of useful tricks like proxy support, user authentication, FTP upload, HTTP post, SSL connections, cookies, file transfer resume, Metalink, and more.

https://curl.haxx.se/docs/manpage.html

Setup Burp Web Proxy

Start your Burp Suite. Open Proxy Tab. Go to Options tab. At the Proxy Listeners section, configure the proxy’s listening interface and port.

Setup Firefox Browser to proxy traffic to Burp

Go to URL address bar and Open about:preferences.

Click Settings button in Network Settings section.

Choose Manual proxy configuration and set 127.0.0.1:8080 as your proxy.

Install Burp Web Proxy certificate to Firefox Trusted Root Certification Authorities store

Visit http://burp URL and Download the Burp’s Certificate.

Go to URL address bar once more and Open about:preferences#privacy.

Click View Certificates.. button in Certificates section.

Open Authorities tab, click Import… button and load the downloaded cacert.der file.

Trust the CA to identify both websites and email users and click ok.

Detecting HTTP Methods using Netcat tool

Open a terminal and execute the following command. You should adjust each of the parameters according to your project’s needs.

nc example.com 80
  • Example.com – Targeted server.
  • 80 – Port.

When the session is opened, type the following:

OPTIONS / HTTP/1.1
Host: example.com
Hit [enter] twice

Detecting HTTP Methods using nmap tool

Open a terminal and execute the following command. You should adjust each of the parameters according to your project’s needs.

nmap --script=http-methods.nse -p80 example.com
  • –script=http-methods.nse – nmap script.
  • example.com – Targeted server.
  • -p80 – Port.

Detecting HTTP Methods using Burp Repeater

Start your Burp Suite. Open the Repeater tab and type your OPTIONS request.

OPTIONS / HTTP/1.1
Host: example.com
Hit [enter] twice.

How to make a PUT request and upload data using Netcat tool

Open a terminal and execute the following command. You should adjust each of the parameters according to your project’s needs.

nc example.com 80
  • Example.com – Targeted server.
  • 80 – Port.

Once your session is opened, type the following:

PUT /hello.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0
Accept-Language: en-US,en;q=0.5
Connection: close
Content-type: text/html
Content-Length: 58
 
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
Hit [enter] twice

How to make a PUT request and upload data using Burp Repeater

Start your Burp Suite. Open the Repeater tab and type your PUT request:

PUT /hello.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0
Accept-Language: en-US,en;q=0.5
Connection: close
Content-type: text/html
Content-Length: 58
 
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>
Hit [enter] twice

How to make a PUT request and upload data using nmap tool

Open a terminal and execute the following command. You should adjust each of the parameters according to your project’s needs.

nmap -p80 example.com --script http-put --script-args http-put.url='/hello.html',http-put.file='/home/user/hello.html'
  • example.com – Targeted server.
  • -p80 – Port.
  • –script http-put – nmap script.
  • –script-args http-put.url=’/hello.html’,http-put.file=’/home/user/hello.html’ – Choose your URI and which file to upload.

How to check if the OWASP Secure HTTP headers have been applied to the server using netcat tool

To accomplish this, you have to retrieve the headers of the web server, compare them with the Secure HTTP headers list and check what is missing and/or has been configured incorrectly. To achieve this, open a terminal and execute the following command. You should adjust each of the parameters according to your project’s needs.

nc example.com 80
  • Example.com – Targeted server.
  • 80 – Port.

Once your session is opened, type the following:

HEAD / HTTP/1.1
Host: example.com
Hit [enter] twice.

You can also retrieve the web server headers and compare them with the OWASP Secure HTTP headers list using the Burp Repeater.