On Wed, May 7, 2008 at 2:32 PM, Jan Rademaker <[EMAIL PROTECTED]> wrote: > > It does work, make sure you're not logged in. > > $ 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">
OK, so what's happening is that the admin is assuming that if you're not logged in, the current URL should be used as the URL to submit login information to. Which means it drops the request path into the form's "action" attribute and, since there are valid things for URLs that'd be incorrectly escaped if we let the autoescaper get at them, it's marked "safe" and so can contain HTML. Since there is a genuine XSS threat here, it needs to be fixed in the current admin and not simply punted to nfa. Optimal solution is to just point the thing at a genuinely consistent login URL and redirect back to where they were trying to go once the user's authenticated (preferably keeping the URL firmly in the address bar the whole time, like we already do with the "next" param for logging in everywhere else). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
