[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <56C60726.8080802@gmail.com>
Date: Thu, 18 Feb 2016 19:02:14 +0100
From: Manuel Mancera <sinkmanu@...il.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com, security@...ian.org
Subject: Re: CVE Request: graphite-web: open redirect
> > https://github.com/graphite-project/graphite-web/issues/1441 > > > two OpenRedirects in /webapp/graphite/account/views.py > > >
Proof of Concept: > > >
http://graphiteSite/account/logout?nextPage=https://www.google.com > >
Is there a response from the author of the code indicating that this >
is a vulnerability? Open redirects to http/https are not universally >
considered vulnerabilities for all vendors and products, e.g., > >
https://sites.google.com/site/bughunteruniversity/nonvuln/open-redirect
> > is probably the most well-known counterargument. >
The authors did not answer.
> > > http://graphiteSite/account/update > > POST:
nextPage=https://www.google.com > > What is the threat model for this
open redirect issue that requires a > POST request? Often, an attacker's
ability to make a client submit a > POST request with an
attacker-controlled parameter means that the > client is executing
JavaScript code from an attacker-controlled site, > and in that case the
JavaScript can send the browser to an arbitrary > http/https URL without
any realistic ability of the client user to > predict that that might
occur. Is there a way in which the existence > of
http://graphiteSite/account/update helps the attacker to accomplish >
the redirect? >
Yes, exist multiple XSS vulnerabilities described in the CVE-2013-5943
[1]. Some XSS were fixed but other not (I found a persistent XSS [2]).
Any user identified in the application could inject javascript code that
could be executed in the victim. Is not possible get the cookie in
javascript because has the "HTTPOnly" flag.
> > Also, inside the logout and update functions, the session should be checked. > > What vulnerability are you reporting here? Are /account/logout and
> /account/update vulnerable to CSRF? >
Yes, both are vulnerable to CSRF (and all the edit graphs are vulnerable
too, deleted included).
[1] https://www.cvedetails.com/cve/CVE-2013-5943/
[2] https://github.com/graphite-project/graphite-web/pull/1470
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
