Category Archives: Research Work

Security checklists when implementing your API  Keys

1 Reply

When building modern API endpoints for your customers,  how to keep API keys secure is likely to be the most crucial question to ask at the initial phase of designing your APIs. Though there is no silver bullet for this question as you need to consider the nature, usage and requirement for your API endpoints, there are still some checklists you could refer to help you to avoid or reduce the potential security risks. 

Taken from https://www.cyberark.com/resources/

Checklist 1: Identify the usage of your API Keys

Before you could implement your API keys in a secure way, it is vital to figure out how your API Keys are going to be used by your clients. Is your API key just an identification string for your server to identify and log the API activity for an App. Or the API key is used for authentication purposes.  Based on the usage for the API keys, different security concerns and the corresponding controls should be evaluated.

API keys are mostly used for App (mobile App, or web application) Identification, Application authentication. In some scenarios it could also be used for user authentication (though it should be called access token rather than API keys in most of these scenarios, to be precise). 

API Key Application Identification

API Keys are typically used to identify the application that is making a call to this API. In this scenario,  it is very likely this API Key will be left in your application and they are pretty easy for any users to spot and extract these kind of API keys. 

Take the widely used Google Analytics API for example, just open some major websites using google analytics tool, you should be able to spot the Google API Key in the source code very easily. Below is a screenshot of an application using Google API Key

As API Keys for application identification are just used for App identification purpose,  these keys will be a) residing in the applications and it should b) not bear permissions to perform any sensitive operations.  Due to these nature of this kind of API keys,  we need check how we could make the API Keys hard to extract from you application and ensure restriction is implemented for this API Keys. Details would be expanded under Checklist 3.

API Key for Application Authentication

API keys could be used for project authentication as well.  When a request with this API key reaches the backend. The backend will check whether the calling application has been granted access to call the API and has enabled the API in this project.  

As opposed to the API for project identification, this kind of  API key is not publicly accessible. Only limited users under this project have access to this API key and then use this API key to perform some sensitive operation with the API .  One typical use case is that, this kind of API key could only be retrieved after a user passes the authentication check (for example, the API could be generated under the dashboard after an authenticated user logs in).  

Since these API keys are bearing authentication characters and could be used to perform sensitive operation,  it is important to understand 1) how this kind of API keys could be accessed, are there any protection implemented 2) Is correct permission is granted to these API keys? Details and some real use cases will be explained in the following section.

API key for user authentication

In some scenarios, the API key can also authenticate users -verifying the person making the call is actually the person they claim to be. Different from API key for App authentication, each user is granted with an API key for a more granular access control rather than an identical API key for the entire App.  We will not unfold the security concerns for this kind of API Key (authentication token) because it is kind of totally a new different story. 

For the API keys used for App identification, we could not really control WHO could access this kind of API key, but just to make it harder for unauthorized users to extract and access it as this kind of API keys has to be part of your App.

Checklist 2: Check who could access the API keys for App authentication

However, for API Keys for app authentication, these API keys are not supposed to be publicly accessible. We could control who could access these API keys. That is exactly the common security risks that I observed when performing penetration testing, missing correct access control to restrict who could access the API Keys. I will use

For example, a project has a group of users with different roles, such as admin, coordinator, team users and only the admin users are supposed to extract and access  the API key for this project. However, in many cases, a user under the App with no permission to access the API keys is still granted permission to access the API Keys due to lack of correct access control or mis-configuration. The following two use cases are real use cases that I found and reported under two private Bug bounty program.

Real Use Case 1 – Lack of Access control:  Under a project hosted under https://vulnerable-example1.com/dashboard,  API Key for this project could be extracted under  https://vulnerable-example1.com/dashboard/configuriation after admin user logs in. However, for a normal user under this project log in, this page https://vulnerable-example1.com/dashboard/configuriation is not rendered with the API key. That seems correct, however, the application is only performing a front end validation to disable the rendering of the API Keys when the logged in user is not Admin. The API key is could be still extract by making a backend request https://example.com/configuration/api/getAPIkey with the session cookie of the normal user if the normal user knows the request URL to extract the API key

Real Use Case 2 – Misconfiguration:  API Key is leaked to users with less privilege under different subdomains due to misconfiguration. For example, a service provider has two subdomains, https://dashboard.vulnerable-example2.com/ and https://document.vulnerable-example2.com/. An admin user logs in to the dashboard under https://dashboard.vulnerable-example2.com/ and could extract the API keys under https://dashboard.vulnerable-example2.com/dashboard/configuriation . To give a better user experience, the API token will also be rendered under https://document.vulnerable-example2.com/howtouseAPI (which is a different domain) after the user logs in. Now, a user without admin privilege logs in to the dashboard, he is not able to get the API token even though he bypassed the front end restriction. However, when the user navigates to the another domain https://document.vulnerable-example2.com/howtouseAPI, the API key is rendered because the backend for this document.vulneable-example2.com just check which APP this user belongs to and render the API key under the page as long as the user belongs to this App.

Both use cases are discovered in two private bounty programs and fixed after reporting them.

Checklist 3:  Deploy methods to reduce the attacking surface for API Keys for App Identification

For API keys residing in the APP,  it is not a matter of if the API keys could be stolen or accessed by a potential malicious user, but how much effort to steal it is worth the return, regardless of your efforts to hide it. However, there are still some ways to reduce the potential attacking surface.

Make it harder for un-authorized user to extract the API Keys from your App

We could not really remove the API Keys from our app completely, otherwise the App will not be able to make API calls to the API endpoints. We could reduce the risk by making it harder for unauthorized user to extract it from our App. Under this security blog post, the user listed several ways to improve the API Key security by

  • using hash-based message for each HTTP request to avoid setting API Keys in the HTTP requests
  • Hide the API Keys in the source code by using Code obfuscation
  • Not store API Keys on the device storage.

Apply API Key Restriction

When using API Keys for APP Identification, it is assumed that these API Keys are ONLY used as an identifier when performing any API calls, it should not be granted permissions to operate some sensitive data. However, that is another common API Keys implemented we observed. For example, some APIs provided by analytics software, it is told the API Keys are just used for identification purpose when sending API requests to the API endpoints, no sensitive operation or malicious API requests could be performed with this API Key even though a malicious user steal the API Keys, it turns out, the API Key could be used to change the App configuration and setting.

To ensure the API Keys are implemented correctly, the developers should restrict the API Keys usage and permissions especially when the API Keys are intended to be used as identifier, not for app authentication.

Conclusion

API Keys are generally not considered secure and they are typically accessible to the clients, which makes it easy for someone to steal an API Key. Since API Keys could be implemented and used in different purpose, you’ll need to consider a variety of factors during the implementation. The above checklist is just the beginning to help you to avoid some common API Key security risks, there are more best practices you could find in the security field.

Using JWT? You need avoid these implementation mistakes

Leave a reply

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWT are widely used in authentication, authorization and information exchange. Among these use cases, the most common scenario for using JWT is for authorization purpose. Once a user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. You may start to ask why not using Session token. One reason is that the JWT is stateless compared with Session tokens, it means that the server side does not have to store the JWT in a centralized DB to perform the validation when a clients sends a request to the server, whereas, the server has to store the session cookies for validation purpose.

To understand the common implementation mistakes of JWT, we need first figure out the structure of the JWT token as most the implementation errors are caused by misunderstanding the structure of JWT token and how each component of JWT are used for.

Structure of JWT Token

A well-formed JWT consists of three concatenated Base64url-encoded strings, separated by dots (.):

  • Header : contains metadata about the type of token and the cryptographic algorithms used to secure its contents. For example
{
  "alg": "HS256",
  "typ": "JWT", 
  "kid": "path/value" //optional
}
  • Payload : contains verifiable security statements, such as the identity of the user and the permissions they are allowed. An example of the payload could be
{
  "username": "test@example.com",
  "id": "new user"
}
  • Signature : it is used to validate that the token is trustworthy and has not been tampered with. When you use a JWT. Signature is piece of encrypted data of the Header and Payload date by using certain encryption method (such as HMAC,SHA256) with a secret which should be residing on a server side.
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

After putting all them together, a JWT looks like

Common Implementation Error

JWT itself is considered as secure method. Most of the security issues discovered against JWT are caused by implementation mistakes.

Leak the secret key

JWT is created with a secret key and that secret key is private to you which means you will never reveal that to the public or inject inside the JWT token. However, sometimes, the developers could mistakenly leak the signing secret to public. For example, the JWT signing secret is stored on a client side javascript functions or stored on a public accessible files. As a consequence, an attacker could bypass the signature verification easily as the attacker could sign any payloads with the secret to put the server side signature validation in vain. Here is one example listed under Hackerone where the developers are adding hardcoded secret in the client side javascript file.

Using Predictable secret key

It is also possible that the developers are copying a piece of code from a sample code base when implementing the JWT on the server side or they are using a simple word (not randomly generated complex string) as the secret value when implementing the JWT on the server side . A brute force attack could easily extract the secret key as the attacker knows the algorithm, the payload with the original information and the resulting signature of the encrypted payload and header. One example listed under Hackerone shows how a developer is using the ‘secret’ as the secret when implementing the JWT on the server side.

Broken JWT Validation

There are numerous way how the JWT validation could be broken during insecure implementation. Here are some typical examples where a broken JWT validation could happen.

  • Not Validate Signature at all. Some developers implement the JWT validation in a wrong way, where they only decode the JWT payload part without validating the signature part before accepting the JWT as a valid token.
  • Not Validate the JWT correctly if None alg is provided. An attacker could or creates a token by setting alg (the signing algorithm) to None in the header. If the server side is NOT validating whether the None alg was really implemented when the JWT was generated. As a consequence, any JWT provided by the attacker with a None value to the alg will be treated as a valid token. To prevent this, the server side should check whether the alg value is the one when the JWT token is generated. If not, the JWT should be treated as an invalid.
  • Not Validate the JWT correctly when alg is changed to HS256 from RS256. HS256 is a symmetric encryption method, the server side is using the same key to generate and validate the JWT. Whereas, RS256 is an asymmetric encryption method, the JWT payload was signed with its private key and validated with the public key, which is known to the public. Now An attacker creates the token by setting the signing algorithm to a symmetric HS256 instead of an asymmetric RS256, leading the API to blindly verify the token using the HS256 algorithm using the public key as a secret key. Since the RSA public key is known, the attacker can correctly forge valid JWTs and bypass the validation method.

Lack of kid header parameter validation

The kid (key ID) Header Parameter is a hint indicating which key was used to secure the JWS. This parameter allows originators to explicitly signal a change of key to recipients. With the key identifier, the consumer of a JWT can retrieve the proper cryptographic key to verify the signature. This simple mechanism works well when both the issuer and consumer have access to the same cryptographic key store.

Since the attacker can modify the kid header parameter, attacker can supply any values in there when it is sent to the sever. If the server is not validating or sanitizing the kid value correctly, it could lead to severe damage.

For example, the kid value in the JWT header is specifying the location of the JWT secret to sign the JWT payload

{
  "alg": "HS256",
  "typ": "JWT", 
  "kid": "http://localhost:3000/vault/privKey.key"
}

For example, the kid value in the JWT header is specifying the location of the JWT secret to sign the JWT payload

{
  "alg": "HS256",
  "typ": "JWT", 
  "kid": "http://evil.com/privKey.key" //Private key supplied by the attacker
}

Now, if the attacker is providing his own private key to the kid parameter and adjust the JWT token, he would be able to generate any valid JWT token.

Other wrong implementation

The above implementation mistakes could lead to very severe security issues, for example, account hijacking and authentication bypass. There are some other implementation bad practice should be avoid when using JWT token.

  • Use JWT token as session cookie. Some applications are using JWT token as a session cookie and it could cause havoc. Let’s say you have a token and you revoke it due to a user logout or any other action, you could not really invalidate the token before its expiration has been reached unless you keep a DB to store these tokens and build a revocation list, which is not the intention of using a stateless JWT.
  • Leak the JWT in referrer header. It is common that a developer attaches the JWT in a URL, for example, user registering and password reset service, and the HTML page of the URL are loading some 3rd party web pages. As a consequence, the JWT could be leaked to 3rd party web pages via referer header if noreferrer is not probably deployed in the web application.

Conclusion

JWT are adopted by more and more applications over the web. If used correctly,  it could help you to build a robust and agile authentication, authorization and information key functions.However, if misused or implemented incorrectly, this technology may put entire systems at risk. This JWT Security Cheat Sheet provides an overview of all these best practices when using JWT in your applications.

Trending Application Vulnerabilities not listed under OWASP TOP 10

Leave a reply

OWASP TOP 10 is the list of the 10 most common application vulnerabilities. It also shows their risks, impacts, and countermeasures. Auditors often view an organization’s failure to address the OWASP Top 10 as an indication that it may be falling short with regards to compliance standards or best security practise.

In general, OWASP TOP 10 outlines the most recurring application security weakness in the application security domain. However, it seems that some trending application security weakness are not listed under current TOP 10 categories after managing two bug bounty programs in the past two years and working as bug hunter in my free time. SSRF ,Cache Poisoning and subdomain takeover are some of these trending vulnerabilities not included in the latest OWASP TOP 10. I believe these vulnerability should get some attentions from security engineers as they could lead to severe security incident.

Sever Side Request Forgery (SSRF)

Server-side request forgery (also known as SSRF) is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain (behind the WAF or internal domain) of the attacker’s choosing.

How SSRF vulnerability could be introduced in your application?

Most likely, SSRF could be introduce when a public facing application allows an end use to add a URL as a parameter. For example, an application allows a user to pull the content, metadata from another web page by inputting the URL of a web page. Or an application allows its users to define a web hook (URL) and the application will send a request to the web hook URL.

What is the impact of SSRF vulnerability?

The severity of impact of successfully exploiting a SSRF could vary a lot depending on how the application is configured or implemented. Sometimes, the SSRF could only be used to scan open ports or IPs of the internal hosts to fingerprint the intranet of an organization. However, sometimes, SSRF could lead to the leakage of sensitive tokens or credentials of your application if your application is powered by AWS, Google Cloud or Azure. The root cause of the recent Capital One data breach was AWS credentials leakage through an SSRF exploitation.

How could you prevent SSRF vulnerability?

Multiple countermeasures could be employed to combat against SSRF by considering the use case of the applications. For example, URL whitelisting or Network segregation are two popular methods to use. URL blacklisting should not be your first preference when remediating the SSRF vulnerability. In a private bug bounty program I joined, the application is using blacklist, like, localhost, 127.0.0.1 to prevent a request to the localhost. However, I was able to bypass it by using http://[::] and http://0.0.0.0/ to bypass the blacklisting. In most of the case, I think network segregation could be a good option if that is affordable for your application.

Web Cache Poisoning

Web cache poisoning is an advanced attacking technology where an attacker exploits the behavior of a web server by modifying web cache with some malicious data and harmful HTTP response containing these malicious cached data is served to other legitimate users.

Why your application could be victim of the web cache poisoning attack?

Some modern application are heavily using CDN web cache method to serve as many client requests as possible without having to retrieve the original content each time. Having a cache layer will significantly reduce the server load of the application. for CDN or web server, it is relying on using cache keys to look up whether a request is cached or not. If the application directly reflects the value of a certain unkeyed header in the response, it could be a good indicator that this application is vulnerable to cache poisoning. Because the header is unkeyed, its value is not part of the cache key and plays no part in deciding about cache hits. If the attacker sends a request where only this header is maliciously modified, the response to this request will be cached. Users subsequently requesting content that matches the same cache key will receive the malicious data injected by the attacker.

What is the impact of Cache Poisoning vulnerability?

The impact of web cache poisoning attack depends on what data could be cached with a crafted request from an attacker and the amount of the traffic on the affected page. Portswigger has a good explanation on the potential impact. If the home page of an organization is vulnerable to web cache poisoning attack, that will be a huge problem to the company as legitimate user will be not able to access the page normally.

How could you remediate web cache poisoning vulnerability?

There is no silver bullet to remove web cache poisoning issue as most applications using web cache has the requirement to use it to ensure a great user experience. One good method would be restrict the cache content to be something purely static.

Subdomain takeover

Subdomain takeover is another trending security issues prevailing in applications. According to portswigger, security researchers have discovered more than 400,000 subdomains with misconfigured CNAME records, leaving many at risk of malicious takeover as a result. The basic premise of a subdomain takeover is a host that points to a particular service not currently in use, which an adversary can use to serve content on the vulnerable subdomain by setting up an account on the third-party service.

How could subdomain takeover happen?

The subdomain takeover issue is always introduced by a human error or mistake. For example, you set up and add a DNS entry blog.example.com and CNAME to a 3rd Party domain, company1.bloghost.com. However, you forget to claim the ownership of the CNAME domain company1.bloghost.com, then an adversary claimed the CNAME domain company1.bloghost.com and hosting some malicious content. Another case would be, you are using AWS to power your application and you create a DNS entry blog.example.com and resolve it to an IP address AWS owned IP address 52.47.73.72 . However, you forget to reserve the IP. Then an attacker claim the ownership of that IP and host some malicious content. As a consequence, all the legitimate user visiting blog.example.com will get the malicious code executed in their browsers.

What is the impact of subdomain takeover?

The impact of subdomain takeover could be very severe. Attackers can then serve malicious content to visitors to the exploited subdomain, and potentially intercept internal emails, mount clickjacking attacks , hijack users’ sessions by abusing OAuth whitelisting, and abuse cross-origin resource sharing (CORS) to harvest sensitive information from authenticated users.

How could you prevent subdomain takeover?

Preventing subdomain takeovers is a matter of order of operations in lifecycle management for virtual hosts and DNS. Depending on the size of the organization, this may require communication and coordination across multiple departments, which can only increase the likelihood for a vulnerable misconfiguration.

Conclusion

With more and more applications are shifting to micro services and serverless platforms. SSRF, Web Cache Poisoning and Subdomain taken over will draw more attention and probably get more spotlights in the cyber security domains. That could explain why SSRF is highly proposed to be added in upcoming OWASP TOP 10 2021.

How to turn Self-XSS into Good XSS

Leave a reply

I am participating in bug bounty programs in the past several years (Apparently my activity on the bug bounty slowed down in the past two years),  I was in fight with a lot of developers to convince  them that they should fix self-exploit XSS vulnerability because of the discrimination they have against self-cross-site scripting.

However, in the past two years,  several researchers demonstrate how to turn slef-xss vulnerability into Good XSS vulnerability and exploit them.  These demonstrations give a bunch of insight for search research on how to exploit self-xss vulnerability by leveraging some trivial security issues.  These for sure would help some developer to understand they should treat slef-exploit xss vulnerability more seriously.

By referring to a list of POCs for exploiting self-xss vulnerability

https://whitton.io/articles/uber-turning-self-xss-into-good-xss/

https://medium.com/@bugbsurveys/self-xss-and-vol2-1b5049e59ae6

http://ashishpathaksec.blogspot.com/2015/06/how-i-convert-self-xss-into-stored-xss.html

http://www.ninoishere.com/airbnb-bug-bounty-turning-self-xss-into-good-xss-2/

  1.  CSRF             :    Login and Logout the victim
  2.  IFrame         :    Frame the page to abtain useful information of the victim
  3.  CSP absue   : Keep part of the victim’s Session by using CSP rule
  4. X-Frame-Options: Abuse same-origin policy. Top window has access to the iframe information, which allows an attacker to get the useful inforamtion, such as CSRF tokens.

To summarize if up,  here is the steps to exploit self-xss vulnerability

Step 1:   Attacker Login and plant XSS codes 

Step 2:  Vitcm to loign to attacker’s acount via CSRF

Step 3:  Victim execute the XSS codes

Step 4:  XSS codes got performed in the Iframe.   This steps could be tricky it all depends of how the authentication process is implemented.  The steps will involve how to switch the victim to Login to their own accounts by using iframe.s

 

 

 

 

How Ignoring Low-Level Security Risks Can Open the Door to Major Attacks

Leave a reply

With the rise in attacks against web applications, cyber security teams naturally have prioritized the elimination of high-risk threats, such as SQL injections and cross-site scripting (XSS) vulnerabilities. The flip side of this is that many cybersecurity teams choose to ignore or delay the remediation of low-level security vulnerabilities in their web applications. Unfortunately, this isn’t a wise strategy. Underestimating the importance of fixing low-level security issues could create a major problem for an organization. Why? By exploiting a combination of seemingly trivial vulnerabilities, attackers can sometimes open up a big security gap that lets them do extreme damage. In this article, I will demonstrate such a scenario, showing how by taking advantage of several unfixed low-level security issues, an attacker could gain full administrator access to a popular web application.

Three low level issues discovered in MyBB

In a recent audit of MyBB, I found three low-level security issues which, if exploited in aggregate, could allow a hacker to gain total control of this open source application which people use to create discussion forums. The issue has been partially addressed in its latest version — MyBB 1.8.7 – so users are no longer vulnerable to the danger described here.

Continue Reading at Qualys Community Blog

How Open Redirection Threatens Your Web Applications

Leave a reply

Open redirection is listed in the OWASP Top 10 for 2013 and 2010 (10th position in both lists) since it is still an active threat in modern web applications. Open redirection occurs when a vulnerable web page is redirected to an untrusted and malicious page that may compromise the user.  Open redirection attacks usually come with a phishing attack because the modified vulnerable link is identical to the original site, which increases the likelihood of success for the phishing attack.

While open redirection is not exactly common, my research was able to uncover several open source applications that were vulnerable. In this article, I describe the results of my research, and some recommendations for avoiding open redirection vulnerabilities in your code.

Vulnerability Found and Fixed in Moodle

Six months ago when I was evaluating the popular open source learning management software Moodle, I discovered an open redirect vulnerability caused by a lack of constraints on the referer parameter. This vulnerability could redirect users to a non-local website and launch a phishing attack. It has been fixed (by adding code to replace the referer with a local URI when the referer value was used as a redirection vector), and the detail has been listed in CVE-2015-3175 and MSA-15-0019.

Proof of Concept

GET /moodle/mod/forum/post.php?forum=1 HTTP/1.1
Host: Yourhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.qualys.com
Connection: keep-alive

By make the request and clicking the “cancel” button in the response page, the user will be redirected to https://www.qualys.com. By taking advantage of this vulnerability, an attacker could launch a phishing attack there very easily.

Research Uncovered More Vulnerable Applications

After submitting this issue and getting it accepted by the Moodle developer team, I decided to commit some time to check whether open redirection is a popular and underlying threat that could damage modern web applications.

I conducted some pen tests against some popular web sites as well as some web applications in a bounty list.

After conducting research off-and-on for several months, the results are bittersweet.  The good news is that most web applications are deployed with some input validation to block redirection to a different domain when there are users’ input requiring a URL value.  However, some web applications do not implement the countermeasure correctly or they do not protect against open redirection at all, which leaves them vulnerable.

More details could be found at Qualys Community blog

Clickjacking: A Common Implementation Mistake Can Put Your Websites in Danger

Leave a reply

The X-Frame-Options HTTP response header is a common method to protect against the clickjacking vulnerability since it is easy to implement and configure, and all modern browsers support it. As awareness of clickjacking has grown in the past several years, I have seen more and more Qualys customers adopt X-Frame-Options to improve the security of their web applications.

However, I have also noticed there is a common implementation mistake that causes some web applications to be vulnerable to clickjacking attack even though they have X-Frame-Options configured. In this article, I describe the implementation mistake and show how to check your web applications to ensure X-Frame-Options is implemented correctly.

The implementation error was caused when there are more than one X-Frame-Options item presented in the response header, please go to my post under qualys community to get the full articles.

Do Your Anti CSRF Tokens Really Protect Your Web Apps from CSRF Attacks

Leave a reply

A research article about CSRF Do Your Anti-CSRF Tokens Really Protect Your Web Apps from CSRF Attacks?  has been published in Qualys Security Lab. This articles indicates how popular web applications are compromised by CSRF attack though they deploy anti-CSRF tokens in their applications.

As described in the article, a webmaster should not consider his/her web application are immune to CSRF attack if though he/she sees the anti-CSRF tokens deployed in his/her web sites. Read more here