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

Reply via email to