Firewall Blocks Javascript

Discussion in 'Javascript' started by rcw1983, Mar 28, 2008.

  1. rcw1983

    rcw1983 Guest

    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.
     
    rcw1983, Mar 28, 2008
    #1
    1. Advertisements

  2. 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.
    Make sure your pages work with javascript disabled.
    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, Mar 28, 2008
    #2
    1. Advertisements

  3. rcw1983

    rcw1983 Guest

    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?
     
    rcw1983, Mar 28, 2008
    #3
  4. 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
     
    Joost Diepenmaat, Mar 28, 2008
    #4
  5. rcw1983 meinte:
    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
     
    Gregor Kofler, Mar 28, 2008
    #5
  6. rcw1983

    rcw1983 Guest

    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, Mar 28, 2008
    #6
  7. rcw1983 meinte:
    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.
    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
     
    Gregor Kofler, Mar 28, 2008
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.