I'd qualify any cookie without httponly flag as "finding", at least a warning.
The developer, or the application owner needs to select those which need it and those which don't. Even if it is "only a tracking" cookie, modification of the value may be harmful somewhere. What w3af can do is to provide a parameter where to specify cookie names to be ignored. But be prepared for a huge name-checking-nightmare as the same cookie name can be used in different realms on the same application and have different purposes there. Just my 2 cent. Achim Am 14.09.2012 16:46, schrieb Andres Riancho: > 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, ------------------------------------------------------------------------------ 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
