How can I check that the form is not posted from a local html page

Discussion in 'ASP General' started by TT, Aug 10, 2004.

  1. TT

    TT Guest

    As title
     
    TT, Aug 10, 2004
    #1
    1. Advertisements

  2. TT

    Evertjan. Guest

    =?Utf-8?B?VFQ=?= wrote on 10 aug 2004 in
    microsoft.public.inetserver.asp.general:
    please elaborate.
     
    Evertjan., Aug 10, 2004
    #2
    1. Advertisements

  3. TT

    TT Guest

    1) Assume I have an asp page (insertRecord.asp) on my server, the page simply
    do somthing if request.form("FormAction")="save", then insert a record in db.
    2) I create a html page locally saved in my own hard disk and the page
    contains the tag <FORM name="LocalPage"
    action="https://server/insertRecord.asp" method="post">, then I SUBIMT it to
    the server's insertRecord.asp.
    3) The result: It works!!!

    Question:
    How can I prevent this case?
    The Problem is that user can edit the html page which located in his hard
    disk and then submit it to my asp on the server.
    Any server variable or other means can check and prevent the user to do this?

    Thank you very much.
     
    TT, Aug 10, 2004
    #3
  4. TT

    Evertjan. Guest

    =?Utf-8?B?VFQ=?= wrote on 10 aug 2004 in
    microsoft.public.inetserver.asp.general:
    <%
    If request.servervariables("remote_addr") = "127.0.0.1" Then 'for localhost
    %>

    or your factual lan ip if you are accessing this page outside your
    localhost "192.168.1.7" or so. Or you can detect a range.
     
    Evertjan., Aug 10, 2004
    #4
  5. TT

    TT Guest

    Dear Evertjan
    Thanks for your reply.

    What I want to do is:
    - "PREVENT the user who edit the html page which is the response of my asp".
    After editing from his local version and then submit to my server's asp. As a
    result, he can overcome some logic or hidden value in my previously responsed
    html page.

    e.g. The responsed html page has a hidden value (record id) in the html
    page. The user save the html page to local, then modify the hidden id and
    submit it again. As a result, he may be able to update another record (which
    he is suppose not be able to view or edit)

    Please advise.
    Thanks.
     
    TT, Aug 10, 2004
    #5
  6. TT

    Evertjan. Guest

    =?Utf-8?B?VFQ=?= wrote on 10 aug 2004 in
    microsoft.public.inetserver.asp.general:
    [please do not toppost on usenet]

    That is aother matter.

    If the html page is on a not trusted user's machine [since you seem to
    have sent it to him/her, correct?], you cannot prevent him/her to edit it
    and use all the knowledge in that file.

    Security is never assured if crucial files are on the client['s ]side.

    So, do not send this file to a non-trusted user.
    [The user rightly should not trust YOU, and be an idiot for uploading
    executables, even html, from YOU. No offence intended, but trust
    is/should be mutual.]
     
    Evertjan., Aug 10, 2004
    #6
  7. Tom Kaminski [MVP], Aug 10, 2004
    #7
  8. TT

    Patrice Guest

    You could :
    - check before updating that access to this id is allowed to the user
    - create a kind of checksum on hidden values so that you can check if the
    user changed a value in your form
    - crypt hidden values (either really or by using a "handle" that in turns
    will return server side the actual value to use)
    - other ?

    Patrice

    --
     
    Patrice, Aug 10, 2004
    #8
  9. TT

    Bã§TãRÐ Guest

    You've just described a form of Cross Site Scripting Attack wich is becoming more and more of a problem to the sites I develop. Depending on the situation I am coding for I do a combination of things.
    Like Tom suggested I will check that Request.ServerVariables("HTTP_REFERER") variable is coming from a set path I want the user to follow, if it doesnt then something is going wrong. This kind of
    attack usually happens with e-commerce checkout processes. If this is the case you really should check the price coming in to the price you should have. It gets complicated having to over code these
    kinds of things but thats what a secure site needs. Secondly, I check session variables. Because they are created on the server they are hard to fake, using a SessionID for a user that hits the site
    will add another layer of checking. Again it depends on the situation and what you're coding for but these are 2 things I use.


    - Bastard
     
    Bã§TãRÐ, Aug 11, 2004
    #9
    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.