mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > PrimeNet

Reply
 
Thread Tools
Old 2008-10-25, 20:56   #1
ixfd64
Bemusing Prompter
 
ixfd64's Avatar
 
"Danny"
Dec 2002
California

22·32·67 Posts
Default v5 security problems

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:

Code:
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:

Code:
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

Code:
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.

Last fiddled with by ixfd64 on 2008-10-25 at 21:17
ixfd64 is online now   Reply With Quote
Old 2008-10-26, 01:43   #2
Mini-Geek
Account Deleted
 
Mini-Geek's Avatar
 
"Tim Sorbera"
Aug 2006
San Antonio, TX USA

10000101011002 Posts
Default

Quote:
Originally Posted by ixfd64 View Post
2. Password visible in URL

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

Code:
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).
Mini-Geek is offline   Reply With Quote
Old 2008-10-26, 01:50   #3
jrk
 
jrk's Avatar
 
May 2008

3×5×73 Posts
Default

Quote:
Originally Posted by ixfd64 View Post
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.

Last fiddled with by jrk on 2008-10-26 at 01:52
jrk is offline   Reply With Quote
Old 2008-10-26, 01:51   #4
jrk
 
jrk's Avatar
 
May 2008

3×5×73 Posts
Default

Also thanks ixfd64 for locating the problems.
jrk is offline   Reply With Quote
Old 2008-10-26, 01:55   #5
jrk
 
jrk's Avatar
 
May 2008

100010001112 Posts
Default

Quote:
Originally Posted by jrk View Post
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.

Last fiddled with by jrk on 2008-10-26 at 01:56
jrk is offline   Reply With Quote
Old 2008-10-26, 01:56   #6
jrk
 
jrk's Avatar
 
May 2008

21078 Posts
Default

Quote:
Originally Posted by Mini-Geek View Post
Hiding it behind a POST is just obscuring that it's still sent in plaintext. It should ideally be sent securely (encrypted).
Seconded
jrk is offline   Reply With Quote
Old 2008-10-26, 17:43   #7
veggiespam
 
veggiespam's Avatar
 
Oct 2002

33 Posts
Default POST still needed, even with SSL

Quote:
Originally Posted by Mini-Geek View Post
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.
veggiespam is offline   Reply With Quote
Old 2008-10-26, 23:38   #8
Mini-Geek
Account Deleted
 
Mini-Geek's Avatar
 
"Tim Sorbera"
Aug 2006
San Antonio, TX USA

22·11·97 Posts
Default

Quote:
Originally Posted by veggiespam View Post
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.
Mini-Geek is offline   Reply With Quote
Old 2008-10-28, 07:59   #9
ixfd64
Bemusing Prompter
 
ixfd64's Avatar
 
"Danny"
Dec 2002
California

22·32·67 Posts
Default

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

Last fiddled with by ixfd64 on 2008-10-28 at 08:07
ixfd64 is online now   Reply With Quote
Old 2008-11-10, 02:24   #10
jrk
 
jrk's Avatar
 
May 2008

100010001112 Posts
Default

Quote:
Originally Posted by ixfd64 View Post
2. Password visible in URL

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

Code:
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.

Last fiddled with by jrk on 2008-11-10 at 02:36 Reason: make that 6 external links
jrk is offline   Reply With Quote
Old 2008-11-10, 05:41   #11
jinydu
 
jinydu's Avatar
 
Dec 2003
Hopefully Near M48

175810 Posts
Default

Quote:
Originally Posted by jrk View Post
if you have not yet disabled referers in your browser.
How do I do that?
jinydu is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Unclear Security Nick Soap Box 182 2021-05-07 13:29
security of the webpage? Unregistered Information & Answers 4 2013-02-08 04:42
Key fob security. Xyzzy Science & Technology 13 2007-03-09 02:39
A security puzzle T.Rex Puzzles 12 2007-02-11 11:54
PrimeNet Security Damian PrimeNet 7 2005-06-21 12:46

All times are UTC. The time now is 03:01.


Fri Oct 22 03:01:42 UTC 2021 up 90 days, 21:30, 1 user, load averages: 1.54, 1.66, 1.75

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.