We tested the client’s web applications – this is the Dashboard Component and the API server (Web API Component).
Access to web applications is available only through authorization (user email and password are required). Next, we use one Cookie to navigate through all sites (domains) of the client (this is Cookie-based authentication). Client services are critical for business, and therefore limiting access to the site and the method of authorization on web applications is very important.
Cookie-Based Authentication uses the mechanism of passing Cookies in HTTP requests. In response to a client request, the server sends a Set-Cookie header that contains the name and value of the cookie, as well as additional attributes: expires, domain, path, secure, httponly. An example of sending a cookie:
Authorization: Set-Cookie: sessionExample =123456789; Path=/; HttpOnly
The client will then automatically send a Cookie header on every request:
Cookie: sessionExample=135797531
Having received a token once, an attacker can use it for many requests to the site – scan protected areas and try to find vulnerabilities in web applications
We suggest using it for authorization on internal and a business-critical websites – Token Based Authentication, also called Bearer Authentication.
Token-Based Authentication uses a server-signed token (bearer token) that the client sends to the server in the Authorization HTTP header with the Bearer keyword or in the request body. For example:
Authorization: Bearer 2468fkafkljh8642kjhlkjad2468
When receiving a token, the server must check it for validity – that the user exists, the time of use has not passed, etc. Token-Based Authentication can be used as part of the OAuth 2.0 or OpenID Connect protocols, or the server can generate the token itself.
Unlike the Cookie approach, the Token approach is stateless.
This means that it does not store any user information in the DB or on the server. The server is only responsible for creating and validating tokens, which allows for more scalable solutions.
This authorization method allows you to flexibly manage authorizations and limit the attacker in attack methods.
At the end of the client security audit, and as you can see, problems and vulnerabilities depend on the authorization mechanism.
- When the “Logout” action was performed from the test page, the authorization token did not lose its validity. This is a potentially dangerous incident, cookie theft/compromise will result in uncontrolled access to resources.
- No additional protection for web application against scanning and hacking attempts (DDoS protection, brute force; OAuth 2.0 and MFA does not apply).
- Cookie expiration time is too long (14 days). This makes it easier for an attacker to compromise the system by compromising the cookie.
- Some resources in the authorized environment (website) are large (about 5 MB), which allows the authorized user to use the Internet channel and server resources to a large extent than necessary (the possibility of a DDoS attack).
- Resources were identified during scanning, which, depending on the content of the HTTP request – the HTTP response time varies (potentially possible DB injection and remote launch of an OS application)
- If the page does not exist – we see а correct error (404 Not Found). If the page exists – but access is restricted, the error changes. This gives additional information for scanning and creating a site map/structure.
- When testing, the HttpOnly cookie attribute parameter can be omitted (this is potentially dangerous). The HttpOnly cookie attribute instructs web browsers not to allow scripts (e.g. JavaScript or VBscript) an ability to access the cookies via the DOM document.cookie object. This session ID protection is mandatory to prevent session ID stealing through XSS attacks.