v5 security problems

[ixfd64]

OK, I've been playing around with v5 a bit and I've noticed a few security issues that should probably be taken care of.

1. XSS vulnerability in login.php

The login.php page takes in an agrument e and displays its contents. A malicious user could create URLs that will cause the victim's browser to execute arbitrary code.

The below example would cause a pop-up containing the user's cookie to appear:

http://v5www.mersenne.org/login.php?e=<script>alert(document.cookie)</script>

The PrimeNet page does not keep passwords across different sessions, so users could not compromise accounts by stealing cookies. However, they could use this vulnerability to create fake forms that will send a user's login data to phishing sites.


2. Password visible in URL

When a user logs in, it loads the following page:

http://v5www.mersenne.org/member/?user_login=[user ID]&user_password=[password]&B1=GO

This is a bad idea! Anyone who checks your browsing history can discover your password. However, this problem could be easily fixed by changing the login method to POST instead of GET.

3. Possible CSRF vulnerabilities in /update/

On the "Update Account" page, many things can be changed simply by manipulating the URL. This is very serious. If someone tricks a victim into visiting a page that contains

http://v5www.mersenne.org/update/?user_password=hello&user_password1=hello&public_name=john_doe&mystats=Y&email=&web_url=&lost_pw_question=What+is+the+secret+number%3F&lost_pw_response=hello&B1=Submit

within an <img> tag, then the user's password and recovery answer would be changed to "hello" without him even knowing. This makes CSRF attacks very easy. Again, this could be fixed by changing the form methods from GET to POST.

[TimSorbet]

Originally Posted by ixfd64

2. Password visible in URL

When a user logs in, it loads the following page:

http://v5www.mersenne.org/member/?user_login=[user ID]&user_password=[password]&B1=GO

This is a bad idea! Anyone who checks your browsing history can discover your password. However, this problem could be easily fixed by changing the login method to POST instead of GET.

Hiding it behind a POST is just obscuring that it's still sent in plaintext. It should ideally be sent securely (encrypted).

[jrk]

Originally Posted by ixfd64

within an <img> tag, then the user's password and recovery answer would be changed to "hello" without him even knowing. This makes CSRF attacks very easy. Again, this could be fixed by changing the form methods from GET to POST.

It is still possible to submit forged POST requests without user interaction (at least with Javascript).

To fix that kind of CSRF vulnerability you'll need a randomized token ID generated by the server for each instance of a form (in a hidden field). When a form is submitted, the server will compare the token from the submitted form with the token it generated (in session). If they don't match (or the server didn't generate a token, or the POST didn't have one), the data is rejected.

The malicious website won't be able to receive this token so it won't be able to forge requests.

[jrk]

Also thanks ixfd64 for locating the problems.

[jrk]

Originally Posted by jrk

randomized token ID generated by the server

Or perhaps you could just send the user's password with each "sensitive" form (in a hidden field, or by asking the user to type it). But that wouldn't be as nice.

[jrk]

Originally Posted by Mini-Geek

Hiding it behind a POST is just obscuring that it's still sent in plaintext. It should ideally be sent securely (encrypted).

Seconded

[veggiespam]

Originally Posted by Mini-Geek

Hiding it behind a POST is just obscuring that it's still sent in plaintext. It should ideally be sent securely (encrypted).

True, SSL would protect it from network sniffing, but you still need POST as this particular GET request is recorded (along with your password as a parameter) in your browser history, any proxy logs, and in the server's http logs. POST parameters are not recorded in these places unless debugging is used.

Thus, use both, SSL and POST.

[TimSorbet]

Originally Posted by veggiespam

True, SSL would protect it from network sniffing, but you still need POST as this particular GET request is recorded (along with your password as a parameter) in your browser history, any proxy logs, and in the server's http logs. POST parameters are not recorded in these places unless debugging is used.

Thus, use both, SSL and POST.

Right, I forgot this, so yeah it should be POST, even if the ideal of having SSL isn't there.

[ixfd64]

PrimeNet now remembers passwords across sessions. A malicious user can now compromise accounts by stealing cookies, using the first vulnerability I pointed out.

[jrk]

Originally Posted by ixfd64

2. Password visible in URL

When a user logs in, it loads the following page:

http://v5www.mersenne.org/member/?user_login=[user ID]&user_password=[password]&B1=GO

This is a bad idea! Anyone who checks your browsing history can discover your password. However, this problem could be easily fixed by changing the login method to POST instead of GET.

Also, the URL is often (by default in most browsers) sent as a referer header to all resources that are accessed via a link on the page.

Images are loaded from chart.apis.google.com and counter.digits.com on the main account page, so they automatically get your name & password after login if you have not yet disabled referers in your browser.

There are at least 6 other external links I can see from the main account page, where clicking them right after login would send your name & password to them.

[jinydu]

Originally Posted by jrk

if you have not yet disabled referers in your browser.

How do I do that?