On Fri, Sep 14, 2012 at 12:08 PM, Stephen Breen <breen.mach...@gmail.com> wrote: > I agree, > > As a tester if I find an XSS flaw I would like to know what cookies I can > access directly. When reporting though I only ever report session cookies > that were not marked as HTTPOnly, the rest aren't usually worth noting.
@Stephen: Makes sense, @All: Any other ideas? What are we missing? > On Fri, Sep 14, 2012 at 10:59 AM, Andres Riancho <andres.rian...@gmail.com> > wrote: >> >> Stephen, >> >> On Fri, Sep 14, 2012 at 11:51 AM, Stephen Breen <breen.mach...@gmail.com> >> wrote: >> > I think it's difficult to identify this, >> >> Agreed, but if we would live in a world where we could identify which >> cookies are for session handling and which for "other stuff"; would >> you say that the ideas expressed in the previous email are correct? >> >> > maybe they should all be logged as >> > informational. >> > >> > Plenty of applications use custom session tokens, it wouldn't be >> > possible to >> > separate these from other types of cookie. >> > >> > On Fri, Sep 14, 2012 at 10:46 AM, Andres Riancho >> > <andres.rian...@gmail.com> >> > wrote: >> >> >> >> List, >> >> >> >> Yesterday I found out that w3af doesn't have a plugin that >> >> verifies if cookies have the httponly flag or not; so I decided to >> >> write it (it was going to be a 2min task) and then I asked myself: "Do >> >> all cookies need to be httponly? What's the use case where a developer >> >> needs to access a cookie from within javascript?" >> >> >> >> I think I solved this, but I need your advice on this: >> >> * All session cookies (PHPSESSID, etc.) need to be httponly, >> >> since there is no use case for a developer to access the cookie from >> >> javascript; and if he's doing it... he's doing something wrong. >> >> >> >> * All other cookies (the ones that are used for tracking, >> >> language, etc.) don't need to be httponly, but it is recommended they >> >> are. There might be some cases where the JS developer wants to access >> >> the cookie that holds the language to show A or B; so that use case we >> >> can't flag as insecure nor incorrect. >> >> >> >> Ideas? >> >> >> >> Regards, >> >> -- >> >> Andrés Riancho >> >> Project Leader at w3af - http://w3af.org/ >> >> Web Application Attack and Audit Framework >> >> Twitter: @w3af >> >> GPG: 0x93C344F3 >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Got visibility? >> >> Most devs has no idea what their production app looks like. >> >> Find out how fast your code is with AppDynamics Lite. >> >> http://ad.doubleclick.net/clk;262219671;13503038;y? >> >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> >> _______________________________________________ >> >> W3af-develop mailing list >> >> W3af-develop@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/w3af-develop >> > >> > >> >> >> >> -- >> Andrés Riancho >> Project Leader at w3af - http://w3af.org/ >> Web Application Attack and Audit Framework >> Twitter: @w3af >> GPG: 0x93C344F3 > > -- Andrés Riancho Project Leader at w3af - http://w3af.org/ Web Application Attack and Audit Framework Twitter: @w3af GPG: 0x93C344F3 ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop