OWASP

OWASP - top 10

OWASP has provided the 10 vulnerabilities we can find in web application.

Command injection

Insecure design

Insecure design refers to vulnerabilities of the architecture of the website. Some bad configuration can be bypass or we can do a brute force attack to have an access to the website through a user account. For instance, an hack to Instagram was due to vulnerabilities for the reset architecture password: https://thezerohack.com/hack-any-instagram

https://owasp.org/Top10/A03_2021-Injection/

Cryptographic failures

https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

Security misconfiguration

https://labs.detectify.com/writeups/how-patreon-got-hacked-publicly-exposed-werkzeug-debugger/

https://owasp.org/Top10/A05_2021-Security_Misconfiguration/

Vulnerable and outdated components

It’s really important for an administrator to keep up to date their components. For instance, if a website use Apache2 as web server and the attacker identify the version of Apache, he can try to find any vulnerabilities for Apache2 and try to exploit these.

So, for a hacker or a penetration tester, the first step is to identify what version of the component the administrator use and after he identifies it, he can find an exploit for execute remote code on the server.

When you identified the version of a component, you can try to find a vulnerability in this database: https://www.exploit-db.com/

Authentification failures

When the developer do not escape fields from user input, like sign up or register a new account, it’s easy to inject SQL request OWASP - Authentication failures

Data integrity failures

The integrity in cybersecurity is a part very important, because, we make sure data still unmodified during the download, because, the data can be corrupted by a hacker or just because the download failed. For checking the integrity, we can use some hash algorithm. It’s important for a web developer to be sure each data are unmodified, so, the developer need to apply integrity verification in their code.

Many websites use external Javascript code, like JQuery. Take this example: a hacker have an access to the JQuery repository and inject code in it, so, every website which use this repository download the malicious code. For resolving that, it’s possible to integrate the hash of the library we want to download, this security mechanism is called Subresource Integrity (SRI):

<script src="https://code.jquery.com/jquery-3.6.1.min.js" integrity="sha256-o88AwQnZB+VDvE9tvIXrMQaPlFFSUTR+nldQm1LuPXQ=" crossorigin="anonymous"></script>

If we want to generate a hash for a specific library, we can use this website: https://www.srihash.org/

JWT

Many websites use cookies for storing some information regarding the user, for instance the username. It’s a bad idea, because, we can change the username to another one and we potentially impersonate someone else. So, for doing that, we can use JWT (JSON Web Token). JWT is a token key-value pair but which integrate the integrity of the token.

A JWT token has three parts:

  • header
  • Payload
  • Signature

A header is like that:

{"typ":"JWT","alg":"HS256"}

A payload contain the cookie itself:

{"username":"guest","exp":1704985737}

And the signature is the hash of the cookie. So, the code below show a JWT. Each parts as encoded with base64, so, you may decode it easily:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VybmFtZSI6Imd1ZXN0IiwiZXhwIjoxNjY1MDc2ODM2fQ.C8Z3gJ7wPgVLvEUonaieJWBJBYt5xOph2CpIhlxqdUw

For vulnerable application, it’s possible to bypass the signature check if we change the algorithm. For instance, the JWT below:

eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0=.eyJ1c2VybmFtZSI6Imd1ZXN0IiwiZXhwIjoxNjY1MDc2ODM2fQ.

Looks like this:

{"typ":"JWT","alg":"none"}
{"username":"guest","exp":1665076836}

Security logging failures

For a website, it’s important to log every action performed by users, because during an accident, the attackers’ activities can be traced and to identify if the attacker has an access to the website, and why not to take action against the attackers.

The information stored in logs should include the following:

  • HTTP status codes and the page locations
  • Timestamps
  • Usernames
  • IP addresses

The following is a list for identify a suspicious attack:

  • Automated tooling can be identified, with the User-Agent or the speed of requests
  • Command payloads can be easily identified, so, detect the payload may indicate an attack against your website
  • Multiple unauthorized request to the website can indicate it’s a Brute-Force attack
  • Localisation of the requests from the geography or with the IP address can give you an idea of the attack from who.

Server-Side Request Forgery (SSRF)

An SSRF is a weakness in the web application when an attack change the behavior of a webserver to send request to another destination:

https://www.cyberuniversity.com/post/ssrf-server-side-request-forgery-quest-ce-que-cest

For instance, when a webserver need to execute a request to a specific server, it’s indicated in the URL: https://www.example.com?server=mysrv.srv, the hacker can change the URL:

https://www.example.com?server=myhacked.srv

So, SSRF can be used for different things describe in the following:

  • Change the behavior between servers
  • Can execute Remote Code Execution (RCE) on the server

HTTP Security headers

HTTP Security Headers

Man-in-the-browser attacks

The MiB attacks is a trojan horse which intercept the user activities between the browser and the security mechanisms for manipulating data.