<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Web App Security (webappsec) Mailing List</title>
<link>http://seclists.org/#webappsec</link>
<atom:link href="http://seclists.org/rss/webappsec.rss" rel="self" type="application/rss+xml" />
<description>Provides insights on the unique challenges which make web applications notoriously hard to secure.</description>
<language>en-us</language><ttl>60</ttl>
<item><title>RE: Unable to impersonate another user although having its cookie</title><description>Posted by Hellman Matthew on Jul 1&lt;p&gt;


&lt;p&gt;
&amp;gt;&amp;gt;The probe I do is opening two sessions with two different users (one
&lt;br /&gt;
&amp;gt;&amp;gt;in internet explorer and one in firefox). Then I copy the cookie
&lt;br /&gt;
&amp;gt;&amp;gt;belonging to one user and substitute it in a request done by the other
&lt;br /&gt;
&amp;gt;&amp;gt;user (using WebScarab). The app throws and error and...</description>
<link>http://seclists.org/webappsec/2009/q3/0012.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0012.html</guid>
<pubDate>Wed, 1 Jul 2009 11:26:06 -0500</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by Heine Deelstra on Jul 1&lt;p&gt;


&lt;p&gt;
CakePHP has open source, why not use it :)
&lt;br /&gt;
&lt;p&gt;http://api.cakephp.org/view_source/cake-session/#line-134 etc.
&lt;br /&gt;
Received on Jul 01 2009

</description>
<link>http://seclists.org/webappsec/2009/q3/0011.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0011.html</guid>
<pubDate>Wed, 1 Jul 2009 18:20:29 +0200</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by jay.tomas_at_infosecguru.com on Jul 01&lt;p&gt;


&lt;p&gt;
I agree that best practices are not followed which is exactly why  
&lt;br /&gt;
there are plenty of nightmares to laugh at. My point was to look at  
&lt;br /&gt;
the least common denominator and say maybe this is working as  
&lt;br /&gt;
designed. cakephp is open source so it may be easier to just look at  
&lt;br /&gt;
the source and see...</description>
<link>http://seclists.org/webappsec/2009/q3/0010.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0010.html</guid>
<pubDate>Wed, 01 Jul 2009 10:42:11 -0500</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by Christopher Firth on Jul 1&lt;p&gt;


&lt;p&gt;
Jay,
&lt;br /&gt;
&lt;p&gt;&amp;nbsp;From re-reading Juan&#39;s message, it sounds like he&#39;s actually logging  
&lt;br /&gt;
in to the application once in a browser and then making the request  
&lt;br /&gt;
that the first browser would normally do in the second browser, with  
&lt;br /&gt;
the cookie from the first browser. In -theory- this shouldn&#39;t lock out...</description>
<link>http://seclists.org/webappsec/2009/q3/0009.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0009.html</guid>
<pubDate>Wed, 1 Jul 2009 23:29:09 +0800</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by S I on Jul 1&lt;p&gt;


&lt;p&gt;
As pUm said:
&lt;br /&gt;
My guess is that it is the user-agent
&lt;br /&gt;
&lt;p&gt;it may be the user agent. Instead of tryin g them all, I sugget you to
&lt;br /&gt;
install the Firefox User-Agent Switcher addon
&lt;br /&gt;
&amp;quot;https://addons.mozilla.org/en-US/firefox/addon/59
&lt;br /&gt;
&lt;p&gt;And select the IE one. Or simply change copy/paste the IE user agent...</description>
<link>http://seclists.org/webappsec/2009/q3/0008.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0008.html</guid>
<pubDate>Wed, 1 Jul 2009 23:39:50 +0900</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by Marc Ouwerkerk on Jul 1&lt;p&gt;


&lt;p&gt;
pUm is right. You can download the code form Cake and see for
&lt;br /&gt;
yourself. In cake\libs\session.php you will see the following check:
&lt;br /&gt;
if ((Configure::read(&#39;Session.checkAgent&#39;) === false ||
&lt;br /&gt;
$this-&amp;gt;_userAgent == $this-&amp;gt;read(&#39;Config.userAgent&#39;)) &amp;amp;&amp;amp; $this-&amp;gt;time
&lt;br /&gt;
&amp;lt;=...</description>
<link>http://seclists.org/webappsec/2009/q3/0007.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0007.html</guid>
<pubDate>Wed, 1 Jul 2009 16:50:53 +0200</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by Irene Abezgauz on Jul 1&lt;p&gt;


&lt;p&gt;
Juan,
&lt;br /&gt;
&lt;p&gt;A few questions to direct this -
&lt;br /&gt;
&lt;p&gt;1. are there any parameters in the request itself that are not the
&lt;br /&gt;
cookie and can be suspected as client/session identifiers?  (either in
&lt;br /&gt;
the body of a POST or as part of the URL in a GET)?
&lt;br /&gt;
2. are you trying to execute a similar request? is there a...</description>
<link>http://seclists.org/webappsec/2009/q3/0006.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0006.html</guid>
<pubDate>Wed, 1 Jul 2009 17:30:03 +0300</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by jay.tomas_at_infosecguru.com on Jul 01&lt;p&gt;


&lt;p&gt;
If I understand the issue correctly you login successfully and get a  
&lt;br /&gt;
cookie. You then try and login a second time with another browser  
&lt;br /&gt;
trying to impersonate the first authenticated user. However, the first  
&lt;br /&gt;
session then gets logged out. To me this would be expected if the app  
&lt;br /&gt;
is...</description>
<link>http://seclists.org/webappsec/2009/q3/0005.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0005.html</guid>
<pubDate>Wed, 01 Jul 2009 10:02:35 -0500</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by Michael Yelland on Jul 1&lt;p&gt;


&lt;p&gt;
Go dload sidejacking, it contains hampster and ferret
&lt;br /&gt;
&lt;p&gt;On Jul 1, 2009, at 9:36 AM, &amp;quot;Irene Abezgauz&amp;quot;  
&lt;br /&gt;
&amp;lt;irene.abezgauz_at_gmail&amp;#46;com&amp;gt; wrote:
&lt;br /&gt;
&lt;p&gt;&amp;gt; Juan,
&lt;br /&gt;
&amp;gt;
&lt;br /&gt;
&amp;gt; A few questions to direct this -
&lt;br /&gt;
&amp;gt;
&lt;br /&gt;
&amp;gt; 1. are there any parameters in the request itself that are not the
&lt;br /&gt;
...</description>
<link>http://seclists.org/webappsec/2009/q3/0004.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0004.html</guid>
<pubDate>Wed, 1 Jul 2009 09:42:21 -0500</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by Brad Causey on Jul 1&lt;p&gt;


&lt;p&gt;
Juan,
&lt;br /&gt;
&lt;p&gt;There is actually a relatively simple way to figure out what exactly
&lt;br /&gt;
is causing the session stealing to fail.
&lt;br /&gt;
&lt;p&gt;Get a local proxy, such as WebScarab.
&lt;br /&gt;
(http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project) and
&lt;br /&gt;
run it on the machine where the browsers are installed.
&lt;br /&gt;
Configure...</description>
<link>http://seclists.org/webappsec/2009/q3/0003.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0003.html</guid>
<pubDate>Wed, 1 Jul 2009 09:20:27 -0500</pubDate></item>
<item><title>Re: Unable to impersonate another user although having its cookie</title><description>Posted by pUm on Jul 1&lt;p&gt;


&lt;p&gt;
just a gues,
&lt;br /&gt;
but try to fake the user agent. something in the http header must be
&lt;br /&gt;
part of the cookie auth. so try them all and then reduce. My guess is
&lt;br /&gt;
that it is the user-agent
&lt;br /&gt;
&lt;p&gt;2009/7/1 Juan Kinunt &amp;lt;kinunt_at_gmail&amp;#46;com&amp;gt;:
&lt;br /&gt;
&amp;gt; Hi,
&lt;br /&gt;
&amp;gt;
&lt;br /&gt;
&amp;gt; I&#39;m auditing a web application...</description>
<link>http://seclists.org/webappsec/2009/q3/0002.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0002.html</guid>
<pubDate>Wed, 1 Jul 2009 15:00:49 +0100</pubDate></item>
<item><title>RE: Unable to impersonate another user although having its cookie</title><description>Posted by Martin ONeal on Jul 1&lt;p&gt;


&lt;p&gt;
&amp;gt; Is this possible? 
&lt;br /&gt;
&lt;p&gt;Ja; possible. May be tagging agent, or source address, or maybe using
&lt;br /&gt;
multiple cookies, or maybe session ID in javascript variable...
&lt;br /&gt;
&lt;p&gt;&amp;gt; Is it the normal operation 
&lt;br /&gt;
&amp;gt; in sessions in CakePHP?
&lt;br /&gt;
&lt;p&gt;No eye dear.
&lt;br /&gt;
&lt;p&gt;Martin...
&lt;br /&gt;
Received on Jul 01 2009

</description>
<link>http://seclists.org/webappsec/2009/q3/0001.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q3/0001.html</guid>
<pubDate>Wed, 1 Jul 2009 14:34:38 +0100</pubDate></item>
<item><title>Article: Setting the appropriate security defect handling expectations in development and QA</title><description>Posted by robert_at_webappsec.org on Jun 15&lt;p&gt;


&lt;p&gt;
Greetings,
&lt;br /&gt;
&lt;p&gt;I have just published the following article on handling application security defects (vulnerabilities) in development
&lt;br /&gt;
and QA.
&lt;br /&gt;
&lt;p&gt;&amp;quot;If you&#39;ve worked in information security you&#39;ve likely had to report a security defect to development in an effort to 
&lt;br /&gt;
remediate the issue. Depending...</description>
<link>http://seclists.org/webappsec/2009/q2/0081.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q2/0081.html</guid>
<pubDate>Mon, 15 Jun 2009 14:08:10 -0400 (EDT)</pubDate></item>
<item><title>XML visibility proxy</title><description>Posted by Scott Sanchez on Jun 11&lt;p&gt;


&lt;p&gt;
Can anyone recommend an open source web proxy solution for getting  
&lt;br /&gt;
visibility in to an XML stream?  e.g to sit in the DMZ and act as the  
&lt;br /&gt;
SSL end point for business partner connections... Giving me a hook to  
&lt;br /&gt;
suck out the data and log it, scan it, etc before opening another SSL  
&lt;br /&gt;
session...</description>
<link>http://seclists.org/webappsec/2009/q2/0080.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q2/0080.html</guid>
<pubDate>Thu, 11 Jun 2009 21:11:38 -0400</pubDate></item>
<item><title>[tool] dradis framework 2.2 released</title><description>Posted by etd on Jun 12&lt;p&gt;


&lt;p&gt;
What is dradis?
&lt;br /&gt;
---------------------------------------------------
&lt;br /&gt;
- dradis is an open source tool for sharing information. Great to be
&lt;br /&gt;
used during security engagements.
&lt;br /&gt;
- It provides a centralized repository of information.
&lt;br /&gt;
- Client/server architecture with a web interface
&lt;br /&gt;
&lt;p&gt;What is new?
&lt;br /&gt;...</description>
<link>http://seclists.org/webappsec/2009/q2/0079.html</link><guid isPermaLink="true">http://seclists.org/webappsec/2009/q2/0079.html</guid>
<pubDate>Fri, 12 Jun 2009 00:28:26 +0100</pubDate></item>
</channel></rss>