Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Denial of Service in isEmail validator #152

Closed
katanacrimson opened this issue Feb 8, 2013 · 21 comments
Closed

Denial of Service in isEmail validator #152

katanacrimson opened this issue Feb 8, 2013 · 21 comments

Comments

@katanacrimson
Copy link

Not sure how reliable this is, but it doesn't appear that the author ever bothered to responsibly report the issue: http://lab.cs.ttu.ee/dl93 ( PDF Warning )

You'll want to check 2.4.2.1 of it where the author provides an example of a claimed Denial of Service vector against this module - not sure if it's applicable after the change to fix issue #109 (commit a643b4f) but I figured it should be addressed after seeing the paper pop up on reddit.

@ProZachJ
Copy link

ProZachJ commented Feb 8, 2013

The current version of validator is vulnerable to this attack. I have confirmed it and can provide an exploitable example.

I am currently using a friend of mines custom ReDOS tool to test all the regexs in this library for issues. Looks like isEmail is vulnerable as well.

@chriso
Copy link
Collaborator

chriso commented Feb 10, 2013

@damianb the author's supervisor, Andres Ojamaa, contacted me privately about the issue and including the following proof of concept

v = require('validator');
s = '';
for (var i = 0; i < 100; i++) {
    s += '-/';
    t = Date.now();
    url = 'http://example.org/' + s + '@';
    try {
        v.check(url).isUrl();
    } catch (e) { }
    console.log('i = ' + i + ", len: " + url.length + ", time: " + (Date.now() - t) + " ms");
}

The denial of service attack that's described in the paper was fixed in a643b4f by replacing the RFC1738 regexp with another, however the replacement regular expression still features at least one repeated subexpression that includes a repeated pattern, i.e. it's probably still prone to a similar attack.

@chriso
Copy link
Collaborator

chriso commented Feb 10, 2013

@ProZachJ no need to post an example. If the regex contains ([pattern]<repetition>)<repetition> then it's exploitable.

@evilpacket
Copy link

Any update on addressing this issue in an upcoming release?

@chriso
Copy link
Collaborator

chriso commented Feb 9, 2014

@evilpacket not yet. What's required is a hand-written parser that doesn't use RegExp's (or at least not the evil patterns). The isURL RegExp is huge so this would require a lot of work.

@freewil
Copy link

freewil commented Mar 3, 2014

Some of these regexes are overly-complicated. Multiline regexes are probably one of my favorite features of CoffeeScript, but the KISS principle probably applies here.

@chriso chriso changed the title Denial of Service in URL validation Denial of Service in isURL/isEmail validators Jun 8, 2014
@AVVS
Copy link
Contributor

AVVS commented Jul 6, 2014

Just stumbled upon a simple example that hangs the checker:
require("validator").isURL("http://www.iwasborn10thousandyearsago.bl...")

Takes several seconds to complete

@chriso
Copy link
Collaborator

chriso commented Nov 23, 2014

Can anyone confirm whether or not isEmail() is still vulnerable? The isURL validator is no longer vulnerable as of f9be99f.

@ProZachJ
Copy link

ProZachJ commented Dec 2, 2014

It appears is isEmail() was replaced here: freewil/express-form@f246069

@chriso chriso changed the title Denial of Service in isURL/isEmail validators Denial of Service in isEmail validator Mar 15, 2015
@N07070
Copy link

N07070 commented Jul 30, 2015

Is the module still vulnerable ?

@ProZachJ
Copy link

No, URL was fixed and isEmail was replaced with a non vulnerable method.

On Jul 30, 2015, at 9:09 AM, N07070 [email protected] wrote:

Is the module still vulnerable ?


Reply to this email directly or view it on GitHub.

@ProZachJ
Copy link

Just to be sure I will run it through my redos tool this afternoon and let you know

On Jul 30, 2015, at 9:09 AM, N07070 [email protected] wrote:

GitHub.

@N07070
Copy link

N07070 commented Jul 30, 2015

okay, great !

@ProZachJ
Copy link

All the regex patterns in that file got the green light.

On Jul 30, 2015, at 11:06 AM, N07070 [email protected] wrote:

okay, great !


Reply to this email directly or view it on GitHub.

@N07070
Copy link

N07070 commented Jul 31, 2015

Perfect. I think it's then safe to close the issue ?

Thanks !

Le 31/07/2015 22:05, Zach Jones a écrit :

All the regex patterns in that file got the green light.

On Jul 30, 2015, at 11:06 AM, N07070 [email protected] wrote:

okay, great !


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#152 (comment).

@chriso
Copy link
Collaborator

chriso commented Jul 31, 2015

I can't find any more issues either. If anyone can find an exploit with the latest version of the library, please let me know.

@chriso chriso closed this as completed Jul 31, 2015
@schaitanya
Copy link

@chriso The following code breaks the [email protected]

v = require 'validator'
email = '"[email protected] via example.com" "[email protected]'
v.isEmail email

Validating this locked up the CPU, it ran for several hours and never finished.

@chriso chriso reopened this Aug 17, 2015
@chriso
Copy link
Collaborator

chriso commented Aug 17, 2015

Thanks for the report @schaitanya.

@chriso chriso closed this as completed in 81045a8 Aug 17, 2015
@chriso
Copy link
Collaborator

chriso commented Aug 17, 2015

@schaitanya the fix is in 4.0.5.

@schaitanya
Copy link

@chriso Awesome. Many thanks for the prompt reply.

@ProZachJ
Copy link

Nice fix, you are nicer than I. I'da just tossed anything with quotes or spaces back as 'not an email address'.

On Aug 17, 2015, at 12:00 PM, chriso [email protected] wrote:

@schaitanya the fix is in 4.0.5.


Reply to this email directly or view it on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants