 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / JavaScript / March 2008Firewall Blocks Javascript
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. 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. > 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.  SignatureJoost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/ 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? > 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 SignatureJoost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/ rcw1983 meinte: > 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? 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 Signaturehttp://photo.gregorkofler.at ::: Landschafts- und Reisefotografie http://web.gregorkofler.com ::: meine JS-Spielwiese http://www.image2d.com ::: Bildagentur für den alpinen Raum 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. rcw1983 meinte: > Sorry, that was a pretty general question. I was just thinking at a > high level what types of things could I do. [quoted text clipped - 4 lines] > 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. Gregor Signaturehttp://photo.gregorkofler.at ::: Landschafts- und Reisefotografie http://web.gregorkofler.com ::: meine JS-Spielwiese http://www.image2d.com ::: Bildagentur für den alpinen Raum > rcw1983 meinte: >> I assume there is some way of tying the [quoted text clipped - 5 lines] > 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. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.