Martin,
I understand the concept, but could you specify which lines of
code in the plugin you would modify and how? Maybe it is something
like :
"""
In all vulnerability descriptions, if the cookie is a session cookie,
don't call it "cookie" call it "session cookie", example:
if expires:
v.setName( 'Secure flag missing in HTTPS cookie' )
else:
v.setName( 'Secure flag missing in HTTPS session cookie' )
"""
On Sat, Sep 15, 2012 at 4:39 PM, Martin Holst Swende <mar...@swende.se> wrote:
> I'd primarily call all cookies with no expiration session cookies - those
> gets cleared when the browser close down. Edge cases are persistent 'session
> cookies', eg used when the user selected 'remember me'... But those maybe
> can be detected at login?
> /Martin
>
> Skickat från min iPhone
>
> 14 sep 2012 kl. 17:32 skrev Daniel Zulla <daniel.zu...@gmail.com>:
>
> Hmm. Do you think it is impossible to write a session cookie detector?
>
> Generally - Sessions sort of look the same, across all languages, frameworks
> and usecases: [a-zA-Z0-9_-]+
>
> The only challenge would be look for a pattern, e.g.:
> - [a-z], [A-Z], [0-9], - and _ need to alternate at least after every second
> (or third) occurence within a string, and the strings needs to have a
> certain length.
>
> What's the shortest session that you have ever seen... Let's say 20
> characters?
>
> Also, the information that the purpose of cookie x could be session
> delivery, can be verified to a certain degree. E.g.:
>
> The w3af could loose the session, go to the login page, play arround, check
> if the server offers a new version of the cookie; re-use the old cookie,
> check if it still works, and so on.
>
> Best,
> Daniel
>
> 2012/9/14 Andres Riancho <andres.rian...@gmail.com>
>>
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
