About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.


JavaScript Login Check

Jeremiah discovered a creative technique for testing to see whether someone is logged in on a particular site. The approach is pretty simple - when you browse a web site, each page is often different depending upon whether you're currently logged in. This may not be the case for every page on the target site, but it's pretty easy to find at least one page where it is. This distinction is the basis of the technique.

Using <script src="">, you can cause a victim's browser to load a page and treat it as JavaScript. If the page isn't really JavaScript, an error is generated. If the page is different depending upon whether the victim is logged in, the error is also different. Pretty simple, right?

Here's an example:

<script src="http://amazon.com/"></script>

If you load a page with this <script> tag, you'll see an error in the error console:

The first error is generated when I am logged in. The second is generated when I'm not. Although only the line numbers differ, that's enough to distinguish between the two.

This could be a nice technique to use in combination with CSRF, because an attack could test whether the victim is currently logged in on a particular site before trying to forge any requests. (It also gives the attacker better statistics for the attack's success rate.)

Try it out for yourself, and be sure to view the source to see how it works. It's easy to add more tests. Here's the one for Amazon:

'http://amazon.com/': { 
    'name': 'Amazon', 
    'login_msg': 'missing } in XML expression', 
    'login_line': '114', 
    'logout_msg': 'missing } in XML expression', 
    'logout_line': '113',     
}

By the way, Zreel Puevfgznf!

About this post

JavaScript Login Check was posted on Fri, 22 Dec 2006. If you liked it, follow me on Twitter or share:

8 comments

1.Jon Tan said:

Merry Christmas to you too mate! All the best to you and yours. :)

Fri, 22 Dec 2006 at 20:00:06 GMT Link


2.Chris Shiflett said:

Thanks, Jon! :-)

Fri, 22 Dec 2006 at 20:09:39 GMT Link


3.Haroon Ahmad said:

Hi Chris,

this is great blog, I sincerely request you and all other writers to post your articles at my articles repository http://fastcreators.com/article/

My friends and me are already posting on , PHP, Apache, Linux, MySQL, AJAX, JavaScript, XML, Telecommunicaitons, Mobile Phones and Cars etc etc

I need support of awesoome writers like you to support my venture to facilitate newbies to find all in one place.

thanks

Sat, 30 Dec 2006 at 08:33:47 GMT Link


4.Hossein said:

Hello Chris!

This is from your book:

If you filter input and fail to escape output, you're likely to encounter database errors (the valid data can interfere with the proper form of your SQL query), but it's unlikely that valid data is going to be capable of modifying the intended behavior of a query. On the other hand, if you escape output but fail to filter input, the escaping will ensure that the data does not interfere with the format of the SQL query and can protect you against many common SQL injection attacks.

May you give me an example about this?

Wed, 03 Jan 2007 at 08:11:00 GMT Link


5.Chris Shiflett said:

Hi Hossein,

Thanks for commenting. Your question is unrelated to the topic being discussed, but I'll answer it anyway.

That particular excerpt is explaining that many security vulnerabilities are a result of developers failing to filter input as well as failing to escape output. For example, O'Reilly is a valid last name and therefore should not be filtered, but it can cause problems in SQL queries if not escaped properly. However, O'Reilly is not a very dangerous attack. (It could be used to reveal a vulnerability, but not much else.)

I think you'll also find that I stress that neither step should be skipped, as neither is a replacement for the other.

Hope that helps.

Thu, 04 Jan 2007 at 17:12:59 GMT Link


6.Ovydyu said:

Hello,

This is a great blog, I think this solution is primitive, as you said but I tried it and it works.

Thank you

Sat, 03 Feb 2007 at 19:05:37 GMT Link


7.Andy James said:

This script may be also useful to determine if a person has an account or not at the first place, in particular website, if I'm familiar with its common used username. Am I correct?

Tue, 13 Feb 2007 at 09:53:53 GMT Link


8.Frank said:

That's a quite interesting approach. But how can it be used to harm anybody. Is it also possible to login then for example as a different person or to spy out the login data?

Sun, 25 Feb 2007 at 00:10:19 GMT Link


Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.