Ajax's Risks

[McKirahan]

Yahoo Mail Worm May Be First Of Many As Ajax Proliferates
<URL: http://www.ddj.com/189500417?cid=RSSfeed_DDJ_All>

[Tony]

McKirahan wrote:

Yahoo Mail Worm May Be First Of Many As Ajax Proliferates
<URL: http://www.ddj.com/189500417?cid=RSSfeed_DDJ_All>

This is fairly old news, and if you read the article, it doesn't show a
risk in the use of Ajax - rather, it shows the risk of not cleaning up
<script> tags in user input.

It also shows Yahoo not thinking ahead.

But nothing really to do with Ajax.

--
"The most convoluted explanation that fits all the available and made-up
facts is the most likely to be believed by conspiracy theorists"

[Kiran]

Tony wrote:

McKirahan wrote:

Yahoo Mail Worm May Be First Of Many As Ajax Proliferates
<URL: http://www.ddj.com/189500417?cid=RSSfeed_DDJ_All>

This is fairly old news, and if you read the article, it doesn't show a
risk in the use of Ajax - rather, it shows the risk of not cleaning up
<script> tags in user input.

It also shows Yahoo not thinking ahead.

But nothing really to do with Ajax.

Hi Tony,

you said
"it shows the risk of not cleaning up
<script> tags in user input."

Can you please suggest me how to do this so I'll do this to my scripts
in web apps.

Thanks
Kiran

[Tony]

Kiran wrote:

Tony wrote:

McKirahan wrote:

Yahoo Mail Worm May Be First Of Many As Ajax Proliferates
<URL: http://www.ddj.com/189500417?cid=RSSfeed_DDJ_All>

This is fairly old news, and if you read the article, it doesn't show
a risk in the use of Ajax - rather, it shows the risk of not cleaning
up <script> tags in user input.

It also shows Yahoo not thinking ahead.

But nothing really to do with Ajax.

Hi Tony,

you said

>"it shows the risk of not cleaning up
> <script> tags in user input."

Can you please suggest me how to do this so I'll do this to my scripts
in web apps.

I can't even begin to suggest it, not knowing what server-side language
you are using. You would be best off asking in the appropriate newsgroup
for that language.

But generally, it's the same as any other server-side cleaning of user
input. You are, for example, escaping quotes and other special
characters before anything goes into a database, right?

Just use a regular expression to search for <script...>...</script> -
once found, you have the option to (a) replace the < and > with &lt; and
&gt; (not always safe), (b) remove the script tage and leave the rest in
place, or (c) remove the script tags and everything between.

--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."

[Anthony Jones]

"Tony" <to****@dslextreme.WHATISTHIS.com> wrote in message
news:12*************@corp.supernews.com...

Kiran wrote:

Tony wrote:

McKirahan wrote:

Yahoo Mail Worm May Be First Of Many As Ajax Proliferates
<URL: http://www.ddj.com/189500417?cid=RSSfeed_DDJ_All>

This is fairly old news, and if you read the article, it doesn't show
a risk in the use of Ajax - rather, it shows the risk of not cleaning
up <script> tags in user input.

It also shows Yahoo not thinking ahead.

But nothing really to do with Ajax.

Hi Tony,

you said

>"it shows the risk of not cleaning up
> <script> tags in user input."

Can you please suggest me how to do this so I'll do this to my scripts
in web apps.

I can't even begin to suggest it, not knowing what server-side language
you are using. You would be best off asking in the appropriate newsgroup
for that language.

But generally, it's the same as any other server-side cleaning of user
input. You are, for example, escaping quotes and other special
characters before anything goes into a database, right?

Just use a regular expression to search for <script...>...</script> -
once found, you have the option to (a) replace the < and > with &lt; and
&gt; (not always safe), (b) remove the script tage and leave the rest in
place, or (c) remove the script tags and everything between.

--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."

I find the best way is to use an XML DOM on the server to build the response
even if the reponse is intended to be a fragment of HTML. Any user entered
text or text from a DB will intrinsically be escaped when added to the DOM.

Of course this doesn't nullify the need to validate incoming inputs to
protect from and detect attempted attacks.

Anthony.

[Terraslate]

Just htmlencode and then the script becomes harmless. java and .net both
have methods to enable you to do this. .net will by default not allow this
content through because of validation being tunred on by default. You'll get
an exception - which is not what you want but at least it is safe. Just
ensure if you switch validation off that you htmlencode user input destined
back for the response stream.

"Anthony Jones" <An*@yadayadayada.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>
"Tony" <to****@dslextreme.WHATISTHIS.comwrote in message
news:12*************@corp.supernews.com...

>Kiran wrote:

Tony wrote:

McKirahan wrote:

Yahoo Mail Worm May Be First Of Many As Ajax Proliferates
<URL: http://www.ddj.com/189500417?cid=RSSfeed_DDJ_All>

This is fairly old news, and if you read the article, it doesn't show
a risk in the use of Ajax - rather, it shows the risk of not cleaning
up <scripttags in user input.

It also shows Yahoo not thinking ahead.

But nothing really to do with Ajax.

Hi Tony,

you said

>"it shows the risk of not cleaning up
<scripttags in user input."

Can you please suggest me how to do this so I'll do this to my scripts
in web apps.

I can't even begin to suggest it, not knowing what server-side language
you are using. You would be best off asking in the appropriate newsgroup
for that language.

But generally, it's the same as any other server-side cleaning of user
input. You are, for example, escaping quotes and other special
characters before anything goes into a database, right?

Just use a regular expression to search for <script...>...</script-
once found, you have the option to (a) replace the < and with &lt; and
&gt; (not always safe), (b) remove the script tage and leave the rest in
place, or (c) remove the script tags and everything between.

--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."

I find the best way is to use an XML DOM on the server to build the
response
even if the reponse is intended to be a fragment of HTML. Any user
entered
text or text from a DB will intrinsically be escaped when added to the
DOM.

Of course this doesn't nullify the need to validate incoming inputs to
protect from and detect attempted attacks.

Anthony.