# WEB SECURITY MINIFIED

### WEB SEC

- Web applications are applications that provide services for users through a browser interface.

#### OWASP
- The Open Web Application Security Project (***OWASP***) is a nonprofit foundation that works to improve the security of software.

##### Top Ten OWASP
- Broken Access Control
- Cryptographic Failures
- Injection
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures.
- Software and Data Integrity Failures.
- Security Logging and Monitoring Failures.
- Server-Side Request Forgery (SSRF)

#### How Web Applications Works

- In order detect an anomaly we should first understand how the technology works. HTTP communication takes place between the server and the client.
- First, the client requests a specific resource from the server.The server receives the HTTP request and sends back an (*HTTP reponse*) to the client after passing it through certain controls and processes. The client's device receives the response and displays the requested resource in an appropriate format.

#### HTTP Requests.
- HTTP Requests are used to retrieve a certain resource from a web server. There is a standard HTTP format, and all request is sent in a different format, then if the web server will not understand it and will send an error to the user or the web server may not be able to provide service


* HTTP Request line consists of a request line, request headers and a request message body.
* A request line consists of the HTTP method and the resource requested from the web server.
* Request header contains certain headers that the server will process.
* The request message body contains data that is intended to be sent to the server.
* The **Get** method state the resources **"/"** is requested from the server since there is no name, a symbol such as "/" means that the web server's main page is requested.
* Browsers use **"Host"** header to describe which domain the requested resource belongs to
* Web application store information on client's devices in **"Cookie"** header. Cookies are used to store session information, so you don't have to re enter credentials when you visit a web applications that requires login.
* The **"Upgrade-Insecure-Requests"** header is used to state that the client wants to communicate with encryption. (SSL)
* **"Accept"** header show the type of data requested.
* **"Accept-Encoding"** show the encoding type that the client understands and is usually compression algorithms names
* **"Accept-Language"** header finds the language information.
* **"Connection"** headers show how the HTTP connection will be made.
* An empty line is put between the HTTP Request Header and the HTTP Request Message Body to make a partition.

#### HTTP Responses.
- When a HTTP request is received, it performs the required contols and processes and the sends the requested resource to the client.
- A HTTP response contains status line, Response Headers, and a Response Body. The status line contains the status cose and HTTP protocol information. There are headers used for numerours purposed within the response header.
- Data related to the requested resource is found within the Response Body.


##### Status Line
* There is information about the HTTP version and HTTP response status code in the Status line, its used to describe the status of the request.

*100 - 199: Information responses*
*200 - 299: Successful responses*
*300 - 399: Redirection messages*
*400 - 499: Client error responses.*
*500 - 599: Server error responses.*

##### Response Headers
- Date: The exact time the server sent the HTTP Response to the client.
- Connection: It states how the connection will be handled, just like int the HTTP request header.
- Server: Information about the server's operating system andthe web server's version.
- Last-Modified: Information about when the requested resource was changed, it's used for the cache mechanism.
- Content-Type: The type of data that is sent.
- Content-Length: Size of data sent.

#### Response Body.
- Contains the resource that was sent by the server and requested by the client.

#### SQLi
- SQL Injections are critical attack methods where a web application directly includes unsanitized data provided by the user in SQL queries.

##### SQL Injection Types
1. **In-band SQLi(classical SQLi)** - a query sent and replied to over the same channel.
2. **Inferential SQLi(blind SQLi)** - queries that receive a reply that cannot be seen, called blind SQLi because the reply cannot be seen.
3. **Out-of-band SQLi** - queries comminucated over a different channel if an attacker is receiving replies to this SQL queries over the DNS.

##### Workings of SQL injection
* The login page is where most SQL injection attacks happen.
* A user is generally expected to enter his/her username and password on the login page. On the other side the web application will use this username and password information to create a query SQL.

SELECT * FROM users WHERE username = 'USERNAME’ AND password = 'USER_PASSWORD'

* This query means bring me all the informatio from the users table whose name is ==*username*== and password is ==*user password*==. If it does find matching credentials it will authenticate else the login will be unsuccessful.

##### SQL payloads
* An attacker will be glad to get an error message, cause he/she can both manipulate the information in the error message for his own advantage and it also shows him that he is on the right path.
* Let's look what if the attacker enters a certain payload like the one below.

'OR 1=1--

* When this payload is sent to the web application it will execute the following SQL query.

SELECT * FROM users WHERE username = "OR 1=1-- AND password = 'secret'

* In SQL, whatever characters come after "-- -" will be perceived as a comment line so queries that come after don't mean anything. To simplify things examining another query.

SELECT * FROM users WHERE username = '' OR 1=1

* Now the query above says "***if the username is empty or 1=1***" it is not really i mportant whether the username area is left empty or not because 1 is always equal to 1.
* That is why this query will be true and it will most probably call the first listing in the database.

This example is a typical SQL injection attack, the attacks are not limited to the above examples the attacker could user SQL to execute commands in the system with the help of SQL commands such as **xp_cmdshell**

##### Leverages with SQL Injection Attacks.
In order to understand why SQL injection attacker are so critically important we need to understand what it can cause.
* Authentication bypass
* Command Execution
* Exfiltrating sensitive data
* Creating/Deleting/Updating database entries.

##### Preventive SQLi measures.
* **Always sanitize data received from a user**: As number rule never trust data received from a user, not only should you sanitize the form data but also do the same with other data (such as headers, URLS, etc)
* **Avoid using raw SQL queries**: if you have a habit of wirting raw SQL queries you should opt to make use of the benefits a framework provides and the security it provides.
* **Use a framework**: Just using a framework will not be sufficient to prevent SQLi attacks but its important to use it as per the docs
* **Keep framework used upto date**: following security updated related to the framework you use.

##### Detecting SQLi Attacks.
There is more than one answer on how can we detect SQL injection attacks.
* **When examining a web request check all areas that come from the user**: because SQL Injection attacks are not limited to the form areas, you should also check the HTTP Headers like User-Agent
* **Look for SQL Keywords**: Look out for words like INSERT, SELECT, WHERE within the data received from users.
* **Check for special characters**: Look for apostrophes (') dashes (-), or parentheses which are used in SQL or special characters that are frequently used in SQL attacks within data received from the user.
* **Familiarize yourself with frequently used SQLi payloads**: Some attackers will still use some common payloads to check for SQLi vulnerabilities, if you are familiar with these payloads you can easily detect SQLi payloads.

##### Detecting Automated SQLi Tools
Attackers use many automated devices to detect SQLi vulnerabilities notably ***sqlmap*** but lets look at a wider picture instead of focusing on specific tool.
With automation we may detect them in the following ways.
* Look at the User-Agent: Automated browser devices generally have their names and versions recorded so checking out the User-Agent to detect these automated devices
* Frequency of requests: A normal user could send 1 request pers second but automated devices are designed to send many requests per second to be able to test payloads as quickly as possible. So you can tell if the requests are made by an automated tools or by the looking at the number of requests per second.
* Contents of Payload: Automated tools usually record their own names in the payload an example with SQLi payload sent would look like **sqlmap' OR 1=1**
* Payload Complication: This detection method may not always work but automated devices send more complicated payloads.