PhpGedView / Discussion / Open Discussion: Cross site scripting vulnerability

Bjørn Gjervik - 2015-06-29

Sitelock has scanned my PhpGedView site and reported problems:

URL:http://www.mysite.xx/PhpGedView/calendar.php?cal=@#DGREGORIAN@&year=2013&month=&day=&action=year
Cross site scripting vulnerability found in args:action,cal,day,month,year

Is there a fix for this? I use v.4.3.0.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Lester Caine - 2015-06-29

Need a bit more information Bjørn ... exactly what are sitelock
complaining about? A quick scan of the code shows that day,month,year
are only used to create a date, and switches to today if one is not
found. So a little more information would be useful.

(may get a duplicate of this I replied by email but it bounced)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bjørn Gjervik - 2015-06-30

Sitelock wont or cant give me more details than whats listed in post 1. Offcourse they want to sell me an fix (300$) but I dont have the cash for that now.

AS I read it, the calender.php has code in it that make it vurneral to hacking.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2015-06-30

Bjørn:
They're trying to scam you. I wouldn't worry about it.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Lester Caine - 2015-06-30

Bjørn ... I've run my checks again and can't see any risk. I get a lot of strange traffic on my phpgedview site, but nothing that gets through to cause problems ... just error messages.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Bjørn Gjervik - 2015-07-01

Maybe, but my site has been hacked 3 times the last 5 yrs.
It's been a easy fix, just recover last backup, but it's anoying when it happens.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stephen Arnold - 2015-07-01

Although there may be no real problem in this code, using a program that has had no updates in four plus years in a world where things can change in a second, can be asking for trouble. phpgedview is an excellent program, but perhaps you should investigate webtrees.net which does receive substantial attention every day and has a very active coding community.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Lester Caine - 2015-07-01
  
  On 01/07/15 15:47, Stephen Arnold wrote:
  
  Although there may be no real problem in this code, using a program that
  has had no updates in four plus years in a world where things can change
  in a second, can be asking for trouble. phpgedview is an excellent
  program, but perhaps you should investigate webtrees.net which does
  receive substantial attention every day and has a very active coding
  
  If someone actually identifies a security problem with phpgedview we
  will get it fixed, but it does it's job nicely and I can't say the same
  for webtrees. I had a go, but it does not fit in with my game plan. If
  you had not messed up the code base SO badly I night have persisted, but
  I WILL be working on an upgrade to phpgedview when time premits.
  
  --
  Lester Caine - G8HFL
  
  Contact - http://lsces.co.uk/wiki/?page=contact
  L.S.Caine Electronic Services - http://lsces.co.uk
  EnquirySolve - http://enquirysolve.com/
  Model Engineers Digital Workshop - http://medw.co.uk
  Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Stephen Arnold - 2015-07-01

@Lester
I've been, and remain, a strong supporter and user of phpgedview. I still have a few hosted clients that wish to remain with that product, which I support. For this reason and many more, I do not badmouth it. For your own reasons, you persist in bashing webtrees. I get that it doesn't fit your ideal. I get that your prefer other SQL products other than MySQL. And I'm happy you plan sometime (now for a long, long sometime) to get around to updating phpgedview. That would be a great service to the phpgedview installed base. But as far as trashing the coders and code of another program, i would politely suggest you keep it to yourself. Guess your mother never taught you "if you can't say something nice, don't say anything at all".

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Lester Caine - 2015-07-01
  
  On 01/07/15 17:19, Stephen Arnold wrote:
  
  "if you can't say something nice, don't say anything at all"
  
  Then please stop pushing webtrees on the phpgedview list ...
  
  --
  Lester Caine - G8HFL
  
  Contact - http://lsces.co.uk/wiki/?page=contact
  L.S.Caine Electronic Services - http://lsces.co.uk
  EnquirySolve - http://enquirysolve.com/
  Model Engineers Digital Workshop - http://medw.co.uk
  Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2015-07-01

I'm with both Lester and Stephen:

If there's a problem with PhpGedView, depending on the severity, we'll get it fixed sooner or later. (Except for Googlemaps and a few other non-essential modules.) I'm willing to tackle Googlemaps, but I need someone else to supply a GEDCOM with geographical co-ordinates in it. I'm NOT going to code these into my own database!

If a new user of PhpGedView asks for help, I'll try to steer them towards Webtrees as being a better-supported alternative. However, I'll stick with PhpGedView for my own site and for a couple of others that my server is hosting. I've been using PhpGedView since 2003, and I know the program quite well. I'd rather not start learning the ins-and-outs of Webtrees or some other alternative when PhpGedView does what I'm asking it to do.

About cross-site scripting: This type of hack only works if PhpGedView stores the hacker's input without validating it and then presents that unvalidated information to another user. The calendar.php script can't do that. So what if the hacker sees his own garbage input?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

rmillet - 2015-12-22

I can confirm there is a XSS (not only in the calendar page):

/calendar.php?x="><script>alert(42);</script>

And even if they are not stored, it can be used against other users by simply making them click on a crafted link.

XSS are very serious vulnerabilities: https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_%28XSS%29

The XSS is in the language selector, the favorite selector and on the calendar manu link.

I'll try to provide a fix soon.

Last edit: rmillet 2015-12-22

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Lester Caine - 2015-12-22

OK that was the info I needed. Once you HAVE a fault you can track it.
The problem is with the handling of $_SERVER['QUERY_STRING'] in session.php.
It's used to create the link for toggle for contextual help and that is where the 'insertion' happens.
Quick hack to fix is
strip_tags(urldecode($_SERVER['QUERY_STRING']))
Means that the page may not display properly, but then they should not be trying to hack the site anyway. Not sure of a better way to clean up the query string as a whole. This is not a problem with the passed variables that was reported, and if the contextual help is disabled the problem goes away.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2015-12-23

I'm working with Lester on this one. A fix is on its way to the SVN repository. Stay tuned.

SVN was updated on 24 Dec. SVN 7116.
SVN was updated on 26 Dec. SVN 7117.

SVN 7116 implements code that will remove all Javascript scripts from any incoming URL. SVN 7117 is the same, but it also logs this event to the PhpGedView log file. Use SVN 7117.

Last edit: Gerry Kroll 2015-12-26

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

rmillet - 2016-01-05

Still not fixed, blacklisting some characters is not a solution because there are lots of evasion techniques.

cf. move mouse over a lang choice or a favorite in drop-down (<select>)
/?x=%22%20onmouseover=%22alert%2842%29%22%20stillfail=%22

I propose a patch wich encode all https://sourceforge.net/p/phpgedview/patches/593/ in the URL query.

Last edit: rmillet 2016-01-05

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Lester Caine - 2016-01-05
  
  On 05/01/16 19:35, rmillet wrote:
  
  Still not fixed, blacklisting some characters is not a solution because
  there are lots of evasion techniques.
  
  cf. move mouse over a lang choice or a favorite in drop-down (
  
  Only having a single language available here that is difficult to check,
  but how do you inject a script link via the favourites list? The fix
  that was applied should prevent any scrip element in the URL being
  forwarded so if you have an example where it's not doing it's job it
  would be welcome.
  
  The other way of fixing the potential hole is simply to block ANY
  content in the url links ... my fix was simply to kill anything that
  contained <script> and crash out.
  
  --
  Lester Caine - G8HFL
  
  Contact - http://lsces.co.uk/wiki/?page=contact
  L.S.Caine Electronic Services - http://lsces.co.uk
  EnquirySolve - http://enquirysolve.com/
  Model Engineers Digital Workshop - http://medw.co.uk
  Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - rmillet - 2016-01-06
    
    If you go to your site http://pgv.local/?x=%22%20onmouseover=%22alert%2842%29%22%20stillfail=%22
    
    The lang swapper code become
    
    <div class="lang_form"><select onchange="document.location=this.value;"><option value="#">Change Language</option><option value="index.php?x=" onmouseover="alert(42)" stillfail="&changelanguage=yes&NEWLANGUAGE=english">English</option><option value="index.php?x=" onmouseover="alert(42)" stillfail="&changelanguage=yes&NEWLANGUAGE=french">Français</option></select></div>
    
    See "onmouseover" is a new attribute, that should not be here.
    So when I click on "Change language" the put my mouse over "English" the script is executed.
    
    With the patch #593 the URL is htmlencode, so the double quote (and some other characters) is escaped and there is no new attribute so no code is executed and page layout is not broken.
    
    <div class="lang_form"><select onchange="document.location=this.value;"><option value="#">Change Language</option><option value="index.php?x=" onmouseover="alert(42)" stillfail="&changelanguage=yes&NEWLANGUAGE=english">English</option><option value="index.php?x=" onmouseover="alert(42)" stillfail="&changelanguage=yes&NEWLANGUAGE=french">Français</option></select></div>
    
    In Gerry solution, only the "<script" tag was encoded, but we can still inject attributes (onmouseover, onerror, ...) and use some evasion to still have a <script>:
    
    http://pgv.local/?x=%22%3E%253cscript%3Ealert%2842%29%253c/script%3E%253cbr%20z=%22 which produces:
    
    <div class="lang_form"><select onchange="document.location=this.value;"><option value="#">Change Language</option><option value="index.php?x="><script>alert(42)</script><br z="&changelanguage=yes&NEWLANGUAGE=english">English</option><option value="index.php?x="><script>alert(42)</script><br z="&changelanguage=yes&NEWLANGUAGE=french">Français</option></select></div>
    
    Same with favoriteform and "Hide Contextual Help".
    
    Edited to better show HTML
    
    Last edit: rmillet 2016-01-06
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
    - Lester Caine - 2016-01-06
      
      On 06/01/16 18:52, rmillet wrote:
      
      |http://pgv.local/?x=">%253cscript>alert(42)%253c/script>| which produces:
      
      Simple answer ... Bugger ;)
      
      I've never like the way PGV handles some of the parameter passing, and
      this just demonstrates why.
      
      normalize_query_string needs to be a bit more aggressive? The favourites
      are only visible once logged in so is a little less of a problem? When
      not logged in The first insert only stops my pop-up menu's appearing
      when not logged in?
      
      Looks like PGV_QUERY_STRING was intended to be the clean QUERY_STRING
      but is still on the todo list. I've just stripped it completely for now
      which breaks a few things, but nothing that can't be lived with short term.
      
      Using $QUERY_STRING = '';
      on http://phpgedview.lsces.org.uk if someone wants to try hacking that
      now :)
      
      --
      Lester Caine - G8HFL
      
      Contact - http://lsces.co.uk/wiki/?page=contact
      L.S.Caine Electronic Services - http://lsces.co.uk
      EnquirySolve - http://enquirysolve.com/
      Model Engineers Digital Workshop - http://medw.co.uk
      Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
      
      If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Gerry Kroll - 2016-01-06
  
  Send me an e-mail: gkroll@keldine.ca. I wish to send you a proposed fix.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Gerry Kroll - 2016-01-07

@rmillet
I'm still waiting for your "real" e-mail address. I can't send a ZIP attachment to your SourceForge address.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Cross site scripting vulnerability

Forums

Help

Cross site scripting vulnerability document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

Cross site scripting vulnerability