Hello folks, I wonder why we don't see web applications use secure cookie recipes like [1] and [2]. There are also existing secure password hashing frameworks such as Solar's [3]. Are developers just unaware of these secure schemes?.
Amusingly a proprietary web application I audited used static tokens. Even if you change your password cookies are still valid. Even passwords are stored as raw MD5 hashes on the database. I think programmers should be taught secure practices from the start. [1] <http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf> [2] <http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf> [3] <http://www.openwall.com/phpass/> Eduardo Tongson NCCS On 11/21/07, James Matthews <[EMAIL PROTECTED]> wrote: > Wordpress never knew how to deal with cookies! > > > On Nov 20, 2007 9:23 PM, Steven Adair <[EMAIL PROTECTED]> wrote: > > Right this problem has existed for a long time, but it's not the end of > > the world for someone to point it out again I suppose. > > > > I think it's obvious that there's another main issue here and that's the > > way WordPress handles its cookies in general. They are not temporary > > sessions that expire or are only valid upon successful authentication. > > The cookies work for ever.. or at least until the password changes. If > > someone uses an XSS attack to obtain the cookies or sniffs them (most > > blogs are just HTTP) they can essentially permanently authenticate. The > > same result occurs with being able to read the database. > > > > Furthermore, one could in theory conduct a bruteforce attack against the > > WordPress password by just making normal requests to the blog but changing > > the cookies that does the double MD5 of the password. You could in theory > > emulate normal continued browsing of the website while sending > > MD5(MD5(password)) over and over with each request via the cookie. Other > > than perhaps a large increase in browsing of the blog, this could possibly > > go unnoticed as an attack -- as it would not be logged anywhere (in most > > instances) that the cookies were being presented. Once authenticated into > > WordPress, the normal blog pages look different, so it would not require > > an attacker to access the Admin area to verify. > > > > Anyway, good to see the CVE is already there. Maybe better session > > management will find its way into WordPress. > > > > Steven > > http://www.securityzone.org > > (..runs on WordPress.. oh noes!) > > > > > > > > > > > This is CVE-2007-6013 since 19th Nov including WordPress ticket #5367: > > > > > > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6013 > > > > > > - Juha-Matti > > > > > > "Steven J. Murdoch" > <[EMAIL PROTECTED]> kirjoitti: > > >> > > >>On Tue, Nov 20, 2007 at 07:08:36PM +0100, Stefan Esser wrote: > > >>Could you elaborate why you consider this news? Most public SQL > > >>injection exploits for Wordpress use this cookie trick. > > >> > > >>I couldn't find it on the Wordpress bug tracker and when I mentioned > > >>it to the Wordpress security address, they did not mention having > > >>heard of it before. I also couldn't find a detailed explanation of the > > >>problem online, nor in the usual vulnerability databases. Blog > > >>administrators, like me, therefore risk sites being compromised > > >>because they didn't realize the problem. > > >> > > >>It seemed intuitive to me that restoring the database to a known good > > >>state would be adequate to recover from a Wordpress compromise > > >>(excluding guessable passwords). This is the case with the UNIX > > >>password database and any similarly implemented system. Because of the > > >>vulnerability I mentioned, this is not the case for Wordpress. > > >> > > >>So I also thought it important to describe the workarounds, and fixes. > > >>If these were obvious, Wordpress would have already applied them. Some > > >>commenters did not think that the current password scheme needs to be, > > >>or can be improved, despite techniques to do so being industry > > >>standard for decades. Clearly this misconception needs to be > > >>corrected. > > >> > > >>I did mention that this was being exploited, so obviously some people > > >>already know about the problem, but not the right ones. Before I sent > > >>the disclosure, there was no effort being put into fixing the problem. > > >>Now there is. Hopefully blog administrators will also apply the > > >>work-arounds in the meantime. > > >> > > >>Steven. > > >> > > >>-- > > >>w: http://www.cl.cam.ac.uk/users/sjm217/ > > > > > > _______________________________________________ > > > Full-Disclosure - We believe in it. > > > Charter: > http://lists.grok.org.uk/full-disclosure-charter.html > > > Hosted and sponsored by Secunia - http://secunia.com/ > > > > > > > > > _______________________________________________ > > Full-Disclosure - We believe in it. > > Charter: > http://lists.grok.org.uk/full-disclosure-charter.html > > Hosted and sponsored by Secunia - http://secunia.com/ > > > > > > -- > http://search.goldwatches.com/ > http://www.jewelerslounge.com > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: > http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/