Firewall Blocks Javascript
rcw1983
developing pages using ASP.NET and recently started to add in some
basic javascript funcitons. In the last page I built I had simple
javascript to add the value of two textboxes and put the result in a
third. I also did some validation in javascript. I ran into a few
cases where a user's firewall was blocking the javascript. Are there
any ways of preventing this? Are there things I can do to minimize
these types of situations?
This raises concerns for me because I'm looking to build some custom
AJAX functionality to avoid the overhead of the .NET UpdatePanel, but
if my javascript might get blocked I might have to reconsider.
Joost Diepenmaat
> I am just getting into more and more web development. I have been
> developing pages using ASP.NET and recently started to add in some
> basic javascript funcitons. In the last page I built I had simple
> javascript to add the value of two textboxes and put the result in a
> third. I also did some validation in javascript. I ran into a few
> cases where a user's firewall was blocking the javascript.
Yes. And they can also switch off javascript themselves, or use firebug
(or plenty of other tools) to manually insert data in the response/form.
Which is why you shouldn't *rely* on javascript to validate input. It
can make the forms more user friendly but you still have to validate
everything at the server end.
> Are there
> any ways of preventing this?
No.
> Are there things I can do to minimize
> these types of situations?
Make sure your pages work with javascript disabled.
> This raises concerns for me because I'm looking to build some custom
> AJAX functionality to avoid the overhead of the .NET UpdatePanel, but
> if my javascript might get blocked I might have to reconsider.
Possibly. On the other hand, the updatepanel demo page seems to fall
back on some kind of non-javascript functionality even with javascript
*enabled* on my browser (firefox 2/linux):
<http://asp.net/ajax/documentation/live/Samples/
UpdatePanelTechnologyOverview1/cs/UpdatePanelContentPageCS.aspx>
You may very well be able to do better.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
rcw1983
Thanks for the reply. Your response has brought up another question
on my mind.
If the user can modify the request/response, how do I secure any
custom AJAX calls?
Joost Diepenmaat
> If the user can modify the request/response, how do I secure any
> custom AJAX calls?
What do you mean? The general strategy to use is
Don't trust the input; check for permissions etc. Don't blindly run
user-provided code. This includes partial SQL queries.
Don't send out or recieve sensitive information unless you have to. For
instance, use sessions instead of passing user credentials around.
Also: http://www.owasp.org/index.php/Main_Page
Gregor Kofler
The same way you validate any "normal" post or get requests. Any XHR
*is* a post or get request. And if the customer modifies the response:
Who cares?
Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
rcw1983
Sorry, that was a pretty general question. I was just thinking at a
high level what types of things could I do.
Take this scenario for example:
Say you are building a webmail app. You have a serverside method for
returning a message based on the message id that is sent via
XmlHttpRequest object. How do you make sure that the user has access
to the message requested? I assume there is some way of tying the
XmlHttpRequest to that user's session on the server. Sorry if this is
a dumb question, but I don't know a lot about implementing AJAX and
I'm just trying to get a better understanding.
Gregor Kofler
> Sorry, that was a pretty general question. I was just thinking at a
> high level what types of things could I do.
>
> Take this scenario for example:
> Say you are building a webmail app. You have a serverside method for
> returning a message based on the message id that is sent via
> XmlHttpRequest object. How do you make sure that the user has access
> to the message requested?
The script setting of the XHR (sends id) gets a response (receives
message). It's the job of your JS to handle the response (display it, or
whatever). There's no difference - as I already stated - for the
serverside script between a "normal" request and a XHR. You can either
have a ss-script solely for handling XHRs, or send an identifier with
your XHR, for allowing the ss-script to deliver "appropriate" content
(for responding to XHRs XML or JSON encoded content are the most popular
choices). Authentification or validation of the request looks exactly
the same as with "normal" requests, too.
> I assume there is some way of tying the
> XmlHttpRequest to that user's session on the server. Sorry if this is
> a dumb question, but I don't know a lot about implementing AJAX and
> I'm just trying to get a better understanding.
Get Firebug. This allows you to track requests and responses
comfortably. There are plenty of websites (including the second one in
my sig) out there to play around.
Duncan Booth
> rcw1983 meinte:
>> I assume there is some way of tying the
>> XmlHttpRequest to that user's session on the server. Sorry if this is
>> a dumb question, but I don't know a lot about implementing AJAX and
>> I'm just trying to get a better understanding.
>
> Get Firebug. This allows you to track requests and responses
> comfortably. There are plenty of websites (including the second one in
> my sig) out there to play around.
>
Also (rcw1983), get the Web Developer add-on for Firefox. Once you've seen
commands like 'Display Form Details', 'Make Form Fields Writable', 'Remove
Maximum Lengths' you'll never ever consider skimping on server-side
validation again.