The explosion of open source and issues related to it

The amount of open source or other third party code used in a software project is estimated as 60-90% of a codebase. Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defences and enable a range of possible attacks and impacts.



Conclusion: even if you perform constant security code reviews, you still might be vulnerable because of third-party components.

Some have tried to do this manually, but the sheer amount of work and data is growing and is time consuming, difficult, and error prone to manage. It would require several full time employees and skilled security analysts to constantly monitor all sources to stay on top.

Description

The WS-Routing Protocol is a protocol for exchanging SOAP messages from an initial message sender to receiver, typically via a set of intermediaries. The WS-Routing protocol is implemented as a SOAP extension, and is embedded in the SOAP Header. «WS-Routing» is often used to provide a way to direct XML traffic through complex environments and transactions by allowing interim way stations in the XML path to assign routing instructions to an XML document.

Taking a minimalist approach, WS-Routing encapsulates a message path within a SOAP message, so that the message contains enough information to be sent across the Internet using transports like TCP and UDP while supporting:

• The SOAP message path model,
• Full-duplex, one-way message patterns,
• Full-duplex, request-response message patterns, and
• Message correlation.

Routing Detours are a type of «Man in the Middle» attack where Intermediaries can be injected or «hijacked» to route sensitive messages to an outside location. Routing information (either in the HTTP header or in WS-Routing header) can be modified en route and traces of the routing can be removed from the header and message such that the receiving application none the wiser that a routing detour has occurred. 

---

For Educational Purposes Only! Intended for Hackers Penetration testers.

---

Issue

The algorithm HS256 uses the secret key to sign and verify each message. The algorithm RS256 uses the private key to sign the message and uses the public key for authentication.

If you change the algorithm from RS256 to HS256, the backend code uses the public key as the secret key and then uses the HS256 algorithm to verify the signature. Asymmetric Cipher Algorithm => Symmetric Cipher Algorithm.

Because the public key can sometimes be obtained by the attacker, the attacker can modify the algorithm in the header to HS256 and then use the RSA public key to sign the data.
The backend code uses the RSA public key + HS256 algorithm for signature verification.

Example

Vulnerability appear when client side validation looks like this:

const decoded = jwt.verify(
   token,
   publickRSAKey,
   { algorithms: ['HS256'  , 'RS256'] }          //accepted both algorithms 
)

Lets assume we have initial token like presented below and " => " will explain modification that attacker can make:

//header 
{
alg: 'RS256'                         =>  'HS256'
}
//payload
{
sub: '123',
name: 'Oleh Khomaik',
admin: 'false'                       => 'true'
}

The backend code uses the public key as the secret key and then uses the HS256 algorithm to verify the signature.

OAuth 2 overview

This article assumes that readers are familiar with OAuth 2. However, below a brief description of it is presented below.

1. The application requests authorization to access service resources from the user. The application needs to provide the client ID, client secret, redirect URI and the required scopes.
2. If the user authorizes the request, the application receives an authorization grant
3. The application requests an access token from the authorization server by presenting authentication of its own identity, and the authorization grant
4. If the application identity is authenticated and the authorization grant is valid, the authorization server issues the access and refresh (if required) token to the application. Authorization is complete.
5. The application requests the resource from the resource server and presents the access token for authentication
6. If the access token is valid, the resource server serves the resource to the application

The are some main Pros and Cons in OAuth 2.0

• OAuth 2.0 is easier to use and implement (compared to OAuth 1.0)
• Wide spread and continuing growing
• Short lived Tokens
• Encapsulated Tokens

— No signature (relies solely on SSL/TLS ), Bearer Tokens
— No built-in security
— Can be dangerous if used from not experienced people
— Too many compromises. Working group did not make clear decisions
— Mobile integration (web views)
— Oauth 2.0 spec is not a protocol, it is rather a framework — RFC 6749

Web application firewall

Web application firewalls (WAFs) are a type of intrusion detection and prevention system and might be either a hardware or software solution. It is specifically designed to inspect HTTP(s) and analyse the GET and POST requests using the appalling detection logic explained below. Web application firewall software is generally available as a web server plugin.

WAF has become extremely popular and various companies offer a variety of solutions in different price categories, from small businesses to large corporations. Modern WAF is popular because it has a wide range of covered tasks, so web application developers can rely on it for various security issues, but with the assumption that this solution cannot guarantee absolute protection. A basic WAF workflow is shown below.



Its main function is the detection and blocking of queries in which, according to WAF analysis, there are some anomalies, or an attacking vector is traced. Such an analysis should not make it difficult for legitimate users to interact with a web application, but, at the same time, it must accurately and timely detect any attempted attack. In order to implement this functionality, WAF developers usually use regular expressions, tokens, behavioural analysis, reputation analysis and machine learning, and, often, all these technologies are used together.



In addition, WAF can also provide other functionality: protection from DDoS, blocking of IP-addresses of attackers, tracking of suspicious IP-addresses, adding an HTTP-only flag to the cookie, or adding the functionality of CSRF-tokens. Each WAF is individual and has a unique internal arrangement, but there are some typical methods used for analysis.