/admin Cross-Site Scripting (XSS) issue!
Chunlei Wu
our security guy points out the url at "/admin" has XSS issue, e.g,
through the link below:
/admin/index.php/%22%3E%3Cscript%3Ealert%283939%29%3C/script%3E/
I am surprised the passed javascript code is indeed executed. Can
somebody verify that? Is it a big threat?
Thanks.
Chunlei
James Bennett
> /admin/index.php/%22%3E%3Cscript%3Ealert%283939%29%3C/script%3E/
>
> I am surprised the passed javascript code is indeed executed. Can
> somebody verify that? Is it a big threat?
Which version of Django is this happening in? Automatic default
escaping of template contents didn't start until after the 0.96
release...
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
mw
(not like today up to date, but pretty up to date)
On May 7, 12:34 pm, "James Bennett" <ubernost...@gmail.com> wrote:
James Bennett
> It worked for me and I have one of the fairly recent copies from SVN.
> (not like today up to date, but pretty up to date)
Visiting the precise URL he pasted, in current Django trunk (SVN
revision 7514), I get a 404.
And I can't see any way that the URL would match something in a prior
version of Django, since there's never been an admin URL pattern that
can match "index.php". or the other junk in that URL.
My best guess is somebody made a 404.html template and is displaying
the raw path of the URL without escaping (or with escaping turned off,
depending on the Django version).
Richard Dahl
work by having malicious scripts executed by another user. Key word
being 'another'. If this works (it gives me a 404) this is an example
where you can XSS attack yourself, but there is no reasonable what to
necessarily prevent this, and besides, you can't save people from
themselves anyway. How do you escape what someone types into the
address bar of a browser?
What happens on your site at /admin/index.php (.php?)?
Does it allow this script (including the unescaped tags) to somehow be
presented to another user for execution?
If not, where is the XSS attack?
Django, at least as of recent builds, escapes the tags when putting
things into the DB and into templates.
A typical example of an XSS attack path would be putting a script into
a form field at a public site and having the next user to view that
entry (blog, perhaps) getting the script back in a subsequent request
and having it execute. Typically the script would then run and send
any cookies to the attackers site (with login credentials for a bank
or some such nonsense). Nothing that any application developer can do
can prevent me from sending the current session cookie for my ebanking
site to a known xss attack url.
I have done some pretty extensive testing of the application security
aspects of Django (by trade I am a security consultant) and find it to
be very reasonably secure, provided sessions timeouts are set to a
reasonable amount of time and cookies do not contain any information
other than a session id. Both of which prevent allowing unauthorized
access to someone's account after that user was the victim of XSS from
another site.
If you review any of the documentation regarding preventing XSS
attacks, they all focus on escaping 'dirty' characters at the server,
prior to database insertion or other processing for further
presentation to other users.
My advice: congratulate the security guru at your company, he
obviously got through a few chapters of Jeremiah Grossman's book;),
but then ask him to explain in detail the actual risk to your app or
your users.
hth,
-richard
AndrewK
You need to be logged out, then it displays a log in window, with an
alert box.
On May 7, 12:10 pm, "James Bennett" <ubernost...@gmail.com> wrote:
Jan Rademaker
$ lynx -source -dump http://localhost:8000/admin/%22%3E%3Cscript%3Ealert%283939%29%3C/script%3E/
| grep alert
<form action="/admin/"><script>alert(3939)</script>/" method="post"
id="login-form">
On May 7, 9:10 pm, "James Bennett" <ubernost...@gmail.com> wrote:
Richard Dahl
alert, I image it has to do with the 'next' property, which is not, I
believe, escaped, as it is not entered into the DB or presented to any
other user. So again, it begets the question: How is the XSS attack
possible?
WARNING! cynical satire ahead!
For those of you willing to succumb to an opt-in XSS attack: please
reply to the list with a valid credit card number, expiration date,
and CVV2 id (it is on the back next to the signature block) thank
you;)
-richard
James Bennett
> Excellent, good catch, when logged out it does indeed display the
> alert, I image it has to do with the 'next' property, which is not, I
> believe, escaped, as it is not entered into the DB or presented to any
> other user. So again, it begets the question: How is the XSS attack
> possible?
I'd imagine the big threat is actually not "scripting" per se, but the
fact that you can tweak the URL that form submits to for a
non-logged-in user. That user then, you hope, ignores the glaring
warning of the URL and submits username/password to wherever you want
him/her to send it.
Easily prevented by users who have half a brain, but still needs
fixing. I've cross-posted to django-dev to get it handled.
James Bennett
found a security problem in Django the correct action is to send email
to secu...@djangoproject.com.
Richard Dahl
entered into the address bar, the 'next' parameter (to my knowledge)
does not persist and cannot be sent to another user. Therefore, if
you want to go ahead and make sure the 'next' variable is escaped,
great, but it is not really increasing security, simply preventing
confusion.
If I said that this condition is indicative of an XSS attack vector I
may as well say that Apache is vulnerable to a Denial of Service
attack because 'after I ran apachectl stop, I could no longer get to
my website'
-richard
James Bennett
> If I said that this condition is indicative of an XSS attack vector I
> may as well say that Apache is vulnerable to a Denial of Service
> attack because 'after I ran apachectl stop, I could no longer get to
> my website'
No, because someone else could put a link on their site to my admin
with this sort of thing embedded. Yeah, it's a big reach in terms of
the user needing to be completely braindead to fall for it, but it's
possible and so we need to take it seriously.
Richard Dahl
should so that people do not start saying 'Django is susceptible to
XSS!' it is the other site that would most likely be vulnerable to
XSS. You would have to go to that site and click a link imbedded
somewhere, and then for no apparent reason, have your own django admin
login presented to you, log in and then it would send something,
presumably your django session id, somewhere else. This is pretty
much just an overly complext XSS attack on the first site, to gain
django credentials, but does not constitute a Django XSS attack.
Perhaps we could say that Django is susceptible to a new class of
attack, but it is not XSS, nor XSRF. I vote we call it either 'ICXSRA'
(for Inconveniently Complex Cross Site Reception Attack), or 'joe'.
You pick.
-richard
On 5/7/08, James Bennett <ubern...@gmail.com> wrote:
>
Chunlei Wu
I guess that does not matter any more.
Thanks for all these replys, which do make me feel better now. I am
not knowledgable enough for web security, so I am indeed thrilled when
our security guy tell me there is a "XSS" threat on on "/admin".
Anyway, whether this may or may not cause real danger, I think it is
worthy to bring it up and fix.
Does the current SVN trunk have this issue fixed? If so, I will just
update my Django.
Thanks.