mersenneforum.org v5 security problems
 Register FAQ Search Today's Posts Mark Forums Read

 2008-10-25, 20:56 #1 ixfd64 Bemusing Prompter     "Danny" Dec 2002 California 1001101000112 Posts 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= 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 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
2008-10-26, 01:43   #2
Mini-Geek
Account Deleted

"Tim Sorbera"
Aug 2006
San Antonio, TX USA

10000101101102 Posts

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

2008-10-26, 01:50   #3
jrk

May 2008

3·5·73 Posts

Quote:
 Originally Posted by ixfd64 within an 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

 2008-10-26, 01:51 #4 jrk     May 2008 100010001112 Posts Also thanks ixfd64 for locating the problems.
2008-10-26, 01:55   #5
jrk

May 2008

3·5·73 Posts

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

Last fiddled with by jrk on 2008-10-26 at 01:56

2008-10-26, 01:56   #6
jrk

May 2008

3×5×73 Posts

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

2008-10-26, 17:43   #7
veggiespam

Oct 2002

33 Posts
POST still needed, even with SSL

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

2008-10-26, 23:38   #8
Mini-Geek
Account Deleted

"Tim Sorbera"
Aug 2006
San Antonio, TX USA

2·3·23·31 Posts

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

 2008-10-28, 07:59 #9 ixfd64 Bemusing Prompter     "Danny" Dec 2002 California 246710 Posts 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
2008-11-10, 02:24   #10
jrk

May 2008

3×5×73 Posts

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

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

2008-11-10, 05:41   #11
jinydu

Dec 2003
Hopefully Near M48

2×3×293 Posts

Quote:
 Originally Posted by jrk if you have not yet disabled referers in your browser.
How do I do that?

 Similar Threads Thread Thread Starter Forum Replies Last Post Nick Soap Box 194 2022-01-15 01:19 Unregistered Information & Answers 4 2013-02-08 04:42 Xyzzy Science & Technology 13 2007-03-09 02:39 T.Rex Puzzles 12 2007-02-11 11:54 Damian PrimeNet 7 2005-06-21 12:46

All times are UTC. The time now is 21:32.

Tue Jun 28 21:32:43 UTC 2022 up 75 days, 19:34, 2 users, load averages: 1.67, 1.44, 1.25