anurag.agarwal_at_yahoo.com wrote:
> Hi Amit
>
> >>For one, it doesn't fully handle situations in which the XSS payload
> can
> >>write compromised data to another (publicly accessible, or at least
> >>attacker accessible) part of the site. For example, an XSS payload may
> >>take the cookie value and "store" it in another part of the site, such
> >>as a page to where comments can be submitted. The attacker then only
> >>needs to frequently poll this section of the site and collect the data.
> I agree but the extent of damage could be limited. For one they wont
> be able to remotely control the victim browser.
Not necessarily. An attacker could deposit instructions in the comments
page, which may be read and acted upon by the XSS payload. It's not as
fast as the standard methods, but it does prove a 2-way communication
line between the attacker and the XSS payload.
> The other thing is if the attacker stores the data on the server (like
> in the approach you mentioned) then from the forensics point of view
> at least it would be clearer to find who the victims were...
>
There are ways around this. The XSS payload may have the attacker's
public key hard-wired in it. It may then encrypt data using that public
key before storing it in the comments page. This way only the attacker
can decrypt the data. Forensics can thus obtain meta-data (size,
timestamp), but not the data itself.
-Amit
-------------------------------------------------------------------------
Sponsored by: Watchfire
The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download today!
https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
--------------------------------------------------------------------------
Received on Aug 15 2007
Intro
