Vulnerabilities | Disposable mail Blog – 10 minute mail

The internet is awesome, but it can also be a pretty dangerous place. This is why we at Disposable mail are always on the lookout for vulnerabilities! If you’d like to learn more about different vulnerability types and staying safe online, check out the articles on this list.


Misconfigured email servers open the door to spoofed emails from top domains

Email authentication configurations are often lacking and leave domains vulnerable to spoofing. To establish how widespread this problem is, we have researched the SPF and DMARC records of the top 500 Alexa domains.

Cross-site Scripting (XSS)

Cross-site Scripting is a very common vulnerability that is easy to exploit. Check out our list of articles about Cross-site Scripting to read more about this vulnerability and learn how to protect your web application.

The basics of Local File Inclusions

In this blog post, we explain what Local File Inclusions are and how you can avoid them and make your code safer.

What is an SQL Injection and how do you fix it?

SQL injection flaws are very critical as they enable a remote attacker to gain access to the underlying database. In the worst case scenario, this allows the attacker to read, write and delete content in the database.

First Encounters Through the Eyes of Our Scanner

Read about how we scan for the most common vulnerabilities and what websites look like through the eyes of our scanner.


This blog series offers an insight into each of the 10 vulnerability types on OWASP’s list. We describe the vulnerabilities, the impact they can have, and highlight well-known examples of events involving them. Of course, we also explain how to discover these vulnerabilities, providing code examples and helpful remediation tips.

OWASP TOP 10: Injection (#1)

OWASP TOP 10: Broken Authentication and Session Management (#2)

OWASP TOP 10: Cross-site Scripting (#3)

OWASP TOP 10: Insecure Direct Object Reference (#4)

OWASP TOP 10: Security Misconfiguration (#5)


With its large number of plugins and themes, WordPress is often subject to vulnerabilities.

WordPress Security

Curious about how you can make your WordPress site more secure? Go ahead and explore our articles on WordPress security to keep up to date with vulnerabilities and best practices.

Temp Mails ( is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

OWASP TOP 10 2013: Cross-site Request Forgery – CSRF – 10 minute mail

Cross-site Request Forgery (CSRF) is one of the vulnerabilities on OWASP’s Top 10 list. Its an attack used to make requests on behalf on the user. OWASP is a non-profit organization with the goal of improving the security of software and the internet. We cover their list of the ten most common vulnerabilities one by one in our OWASP Top 10 blog series.


Cross-Site Request Forgery, or CSRF attack, is when an attacker is able to make requests on behalf of a user. Typically the attacker takes advantage of the fact that the user is already authenticated. In other versions of this attack (e.g. Login CSRF) that is not needed.

As the attacker cannot read the response, it is not of any use to force the victim to retrieve data. CSRF only targets state-changing requests such as changing credentials, transferring funds, modifying settings, etc.


In 2010, OWASP ranked this vulnerability as 5th on their list of the most important vulnerabilities. In 2013, it dropped to the 8th place and its prevalence went from widespread to common thanks to improvements of some frameworks to automatically protecting against this and overall awareness of this attack. However we still see this vulnerability commonly present, and this report from CVE Details shows that applications are still at risk to cross-site request forgery today.

CSRF has begun to appear is in API calls. It has become more popular to execute sensitive requests over different APIs instead of regular requests, and developers may forget a token is needed there as well. A web vulnerability scanner can be added to developer workflow to assist with checking the code, including CSRF and other OWASP security risks, before deployment.

Log in to check your security status for CSRF vulnerability.

Potential impact of Cross-site Request Forgery

Assuming the target is a normal user, a successful attack could lead to any state-changing request being executed on the user’s behalf. The same applies if an admin is the target, but the request would then be executed with admin privileges. In the latter case it could potentially lead to a full system takeover.


The user can be compromised when clicking a link or visiting a page with the link embedded. The latter for example could be an img tag. That can be implanted by hacking a site the attacker knows the user will visit, MITMing the user, send the user an email to trick them to click the link.

It is sometimes possible to store the CSRF attack vector on the vulnerable site, which would make this more likely to be abused as it would be easier to spread. An example would be a forum where an attacker could include a picture and then choose the crafted CSRF link as source.

Well-known events

Less than three years ago security researchers were able to identify that 300.000 home routers had been compromised. The DNS settings had been changed, giving the attacker control over every request sent from devices using the router. The attack method used varied, and for some of the routers they used CSRF vulnerabilities. By simply visiting a webpage with the CSRF payload, all traffic from thereon could be controlled by the attackers.

How to discover Cross-site Request Forgery

  • Look for any link, form or API call that lacks a CSRF token or other protection.
  • There are also some common misconceptions about CSRF protection, look into that and see if the developer seems to have fallen for any of them. See the Remediation section for examples of what is not enough.

Example of CSRF vulnerable application

Let’s assume there is a bank interface that looks something like this:

The request for sending 10 USD to account #1234 would look like this:

As there is no token or any other protection mechanism implemented, an attacker can send this link to a logged-in user. When the user clicks the link, 10 USD will be transferred to the account #1234.

An attacker could buy an advertisement on a popular website in the same as country the bank, and include the snippet of code below to carry out CSRF attacks. The potential damage should be obvious.


  • For every request that is considered important or sensitive, an unpredictable token should be included. These must at a minimum be unique per user session, but could be randomly generated for each request.
  • Another solution that is often used with the most sensitive forms is re-authentication, meaning that the user needs to enter the password twice. A common application of this are change-password fields, but the same method can be implemented with other forms as well with the same result. However, the user experience could be aggravated by having to enter the password all the time, so it should be used sparingly.
  • Today, many frameworks have built-in protection mechanism against CSRF attacks. Check to see if it’s been enabled for your applications.
  • Read more details on the OWASP CSRF Cheat Sheet.

Common misconceptions of CSRF protection

A misconception we often debunk is whether CAPTCHA is sufficient CSRF protection.  Long story short, it’s not! You can read the details of why CAPTCHA and reCAPTCHA may not prevent cross-site request forgery here.

Another common misconception is that it is sufficient to only accept POST requests as the attacker then cannot create a malicious link. This is false! With just a few lines of JavaScript the attacker would be able to bypass this.

Remember that IP addresses, session cookies, local storage, etc., are always included in requests, even the forged ones, so only checking such information does not protect against CSRF. An XSS vulnerability would bypass most of the CSRF protections, with re-authentication being the only exception.

How Disposable mail can help

We provide a quick and easy way to check whether your site passes or fails OWASP Top 10 tests. Disposable mail is a web security scanner that performs fully automated tests to identify security issues on your website. It tests your website for over 1000 vulnerabilities, including cross-site request forgery and the 2017 OWASP Top 10, and can be used on both staging and production environments. Sign up for a free trial to find out if you are vulnerable.

Looking to discuss a solution or implementation? Contact our support at [email protected]!

Temp Mails ( is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

CAPTCHA does not prevent cross-site request forgery (CSRF) – 10 minute mail

In our dialogues with customers, we often come across cross-site request forgery (CSRF) findings marked as False Positives due to having CAPTCHA implemented. There is a widespread misconception that having CAPTCHA in place protects against CSRF. In most cases, this is incorrect at best and dangerous at worst. CAPTCHA does not prevent CSRF – here’s why.

Why CAPTCHA does not prevent CSRF attacks


CAPTCHA or Completely Automated Public Turing test to tell Computers and Humans Apart, is a challenge prompt that appears, asking you to prove you are human by reproducing distorted letters and numbers into a box to complete your form request. Click here for further explanation.

CAPTCHA image with distorted letters

Image source: A example of CAPTCHA challenge from Wikipedia

To understand why CAPTCHA does not guarantee CSRF protection, let’s look at how it works:

On the client side:

  1. The browser requests a challenge from the CAPTCHA provider.
  2. The browser retrieves the challenge/image and the ID of that image.
  3. The user solves the challenge/image by transcribing it into an input field.
  4. When the user clicks submit, the browser sends the challenge ID and the transcribed data to the server.

On the server side:

  1. The server receives the challenge ID and the transcribed data from the user.
  2. The server forwards these two parameters to the CAPTCHA provider that in turn confirms if it was correctly solved or not.

The server never knows who solved the CAPTCHA, just that it has in fact been solved. This is the core principle of all CAPTCHA systems.

An attack scenario would look like this:

  1. The attacker requests a challenge from the CAPTCHA provider.
  2. The attacker saves the challenge ID and solves it.
  3. The attacker compiles the CSRF request and includes both the solution and challenge ID in the request.
  4. The server retrieves the request from the user, confirms it is a valid solution, and accepts the action.

(Google uses a slight variation on this. The user sends a request to Google as soon as they have solved the CAPTCHA and the received token is then sent to the website for validation, but the result stays the same.)

This is nothing new. Egor Homakov described this exact attack scenario back in 2013 and he was not the first to have done so. It’s possible to buy challenge:solution pairs online from people that have already solved them, making this attack even more practical.

The official OWASP page has recommended implementing a CAPTCHA for a long time, so it is not surprising that CAPTCHA is believed to be a solution. OWASP vaguely mentions that CAPTCHA needs to be implemented correctly, but this is easily misinterpreted.

While challenge-response is a very strong defense against CSRF (assuming proper implementation),

We often iterate this same attack scenario explanation to our customers that report CSRF findings as false positives to demonstrate that implementing CAPTCHA is not enough. We also receive questions about the next version of Google reCAPTCHA and whether it protects against CSRF attacks.

Google reCAPTCHA

Neither CSRF or Cross-Site Request Forgery yield any results in the documentation for Google reCAPTCHA. This is important because even if it turned out to actually protect against CSRF right now, relying on it for all future sessions can be risky. The way reCAPTCHA works could be changed anytime and because the documentation does not mention CSRF protection, Google is not obligated to ensure reCAPTCHA works as a CSRF defense.

Even though reCAPTCHA is not intended to protect against CSRF, we decided to take a closer look. Debunking the myth of reCAPTCHA as CSRF protection was as easy as looking at the official documentation.

reCaptcha does not guarantee CSRF protection

Server Side Validation –

The secret is static for all solved CAPTCHA’s on your website and therefore also not relevant for this question. The only thing that matters is the response, and possibly the optional remoteip. Note that the same verification process is used for both reCAPTCHA V2 and Invisible reCAPTCHA, so this ‘problem’ is universal. Note that this is not a criticism of Google reCAPTCHA as their goal has never been to prevent CSRF attacks in the first place.

It would be possible to use the remoteip which would make a CSRF attack much more difficult as the attacker and the user would have to use the same IP address. However, this is not something we would recommend as it also prevents legitimate scenarios where a user, for example, receives the CAPTCHA over a mobile connection, automatically connects to home wifi and thereafter submits the actual request over that connection.

We can hereby conclude that reCAPTCHA and CAPTCHA do not prevent CSRF by default, and assert that the vulnerability to CSRF attacks needs to be monitored even though these modules are in place.

Check if you’re vulnerable to CSRF by running a free Disposable mail security scan.

Temp Mails ( is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Do not dismiss the small vulnerabilities! – 10 minute mail

Never dismiss a small vulnerability because its impact on its own is negligible. Seemingly innocent vulnerabilities can be combined into something much more dangerous or, at the very least, be used to aid in an attack.

Sometimes a small vulnerability is overlooked as the impact is not seen as dangerous. What is often missed in this type of scenario is what happens when vulnerabilities are combined. This is often called chain vulnerabilities.

Combining vulnerabilities

It is way too common to disregard vulnerabilities because they have no big security impact by themselves.

This is not a technical blog post with awesome well thought-out examples of combined vulnerabilities. This is food for thought, to introduce the mindset and make you think a few steps ahead. This is how the examples should be read.

How vulnerabilities can be combined

Example 1

Imagine there is a developer page publicly accessible from the internet. The only thing this page does it print the whole request onto the page. At the first glance this looks very innocent, how much does seeing their own request really help the attacker?

Now, imagine there is also an XSS on the same domain. All of a sudden the printed request becomes very bad, as the hacker is able to steal all cookies with the XSS. An XSS can read the content of the webpage but not the sent headers when HTTPOnly is used. Such a debug page will therefore result in an HTTPOnly bypass.

Example 2

Sometimes developers deprioritize upgrading software that is only accessible locally. Vulnerable software that only allows requests from localhost/the same server does not sound that scary.

There is another vulnerability type called SSRF, Server Side Request Forgery. In short, it means that an attacker is able to force the web server to make custom requests to the internal network.

Now combine these two and an attacker is able to exploit the vulnerable software that was only running locally. Neither of those things sound that dangerous, but combined, they can have a considerable impact!

Example 3

Login/logout CSRF is another vulnerability we have written about before. It enables the attacker to forcefully log the victim in to the attacker’s own account.

Once again, at first glance this looks innocent enough. What good does it do the attacker that they can give away their own account? However, combine it with an XSS that previously only affected your own account and you now have an XSS affecting anyone.

Example 4

A great write-up on the subject is this one written by Orange Tsai, combining four different vulnerabilities resulting in the ability to execute code on Github’s servers.


Many of these combinations are hard to automate. Some can of course be combined automatically, but others still require human creativity to fully understand the potential impact.

Because of this, minor issues reported by tools such as Disposable mail should not be ignored. Critical findings need to be prioritised, but it is a good idea to try and think about how an attacker might exploit minor issues. Maybe even the most harmless ones can escalate into something critical?

To check your site for both minor and critical security issues, sign up for a free Disposable mail trial and run a scan. You will receive a detailed report with all the identified vulnerabilities and tips on how to fix them.

Temp Mails ( is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.