Re: Cross Site scripting prevention at browser
- From: run_signature_script_for_my_email@xxxxxxxxxxx (laura fairhead)
- Date: Sun, 4 Dec 2005 23:24:30 +0000 (UTC)
On 23 Nov 2005 13:54:53 GMT, jKILLSPAM.schipper@xxxxxxxxxx wrote:
>Madhusudhanan Chandrasekaran <mc79@xxxxxxxxxxxxxxx> wrote:
>> Hi,
>>
>> I am sorry if this is not appropriate group for my posting.
>>
>> Given the present state of XSS attacks, most of the existing defenses
>> address prevention from the server side (static and run time checks).
>> My question is on preventing cross-site scripting at the client(browser)
>> level. As I read about them, few questions arise.
>>
>> (i) How is JavaScript handled at the browser level?.
That is a very general question. Maybe you can find some information
from Sun Microsystems documentation, check their website.
>> (ii) In order to prevent such attacks, is it possible for my browser to
>> stop executing code which is not in the visited domain?.
(How) do you know for sure the visited domain is what you think it is?
If your client was comprimised, or it;s DNS server, or any
of the routers along the way.... That's just the start of it,
maybe you went to www.somedomain.com because you clicked a "link"
on another site but what that action actually did was sanction
a visit to somewhere else....
> If such a technique
>> can be incorporated, then I can use the brower's trust model to detect
>> (and decide whether the script is from the site I visited) injected scripts
>> downloaded from a different source.
It's theoretically possible (although practically not probable) that someone
can completely hi-jack your connection to the server. Trust is a mutual
thing; it can't be established by the client alone.
Well, I don't really understand completely what you're referring to
by "XSS attacks". It would be nice if you posted more specific information
about what you think that is (I'm just giving general answers because
I don't really understand what you mean exactly :)
byefornow
laura
>>
>> Is such an approach feasible. If not please tell me why?.
>>
>> Thanks in advance,
>> -Madhu
>
>Some answers, and opinions...
>
>i) Not at all, if properly configured. Otherwise, it is executed by a
>scripting engine in what should be a secure sandbox. I don't know that
>much about this, and if you don't specify what browser you mean...
>
>ii) In general, no. The whole point of XSS is that the browser's
>'security' is bypassed by injecting code into the page visited. (As a
>simplistic example, consider a forum that echoes the raw username you
>enter; then take '3v1l<script>l33t.sploit()</script>' as username, and
>any visitor will be subjected to l33t.sploit(). However, it *is* the
>webserver you are trying to connect to.
>
>Since the injected code often relies on a file being available on
>another server, making sure that the browser does not attempt to get
>files from a different domain name than the one currently being visited
>would work against many current attacks. However, it would attack the
>implementation, not the vulnerability. (And Firefox, at least, has an
>option to disallow getting images from another webserver or somesuch -
>IE, of course, is so broken that fixing it is hopeless...)
>
> Joachim
--
echo alru_aafriehdab@xxxxxxxxxxxxx |sed 's/\(.\)\(.\)/\2\1/g'
.
- Follow-Ups:
- Re: Cross Site scripting prevention at browser
- From: Madhusudhanan Chandrasekaran
- Re: Cross Site scripting prevention at browser
- From: Volker Birk
- Re: Cross Site scripting prevention at browser
- Prev by Date: Free HTTPS tunnel: Calling for beta testers
- Next by Date: finding holes in the program
- Previous by thread: Free HTTPS tunnel: Calling for beta testers
- Next by thread: Re: Cross Site scripting prevention at browser
- Index(es):
Relevant Pages
|
