Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. A Change of Season
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2004
    Location
    Next Door
    Posts
    2,650
    Rep Power
    171

    Does form input hidden need to be escaped?


    As this does nto show any alert box, it doesn't seem like it needs to be escaped. Just making sure. Can someone confirm this is fine to be in source code:
    Code:
     <input type="hidden" name="date" value="<script>alret('g');</script>" />
  2. #2
  3. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,957
    Rep Power
    1045
    Hi,

    I think there are several misunderstanding (like in your previous thread).

    First of all, this is not an example of cross-site scripting. Check what you got: You have an input element with some value. The value happens to be HTML syntax, but that doesn't matter. It's just data. It doesn't get interpreted as HTML, because it's in a data context, not an HTML context. It's as good or bad as putting "zxcvbnm" in there.

    Trouble starts when people get into the HTML context and are able to manipulate existing elements or add new ones. Take this example:

    Code:
    <input type="hidden" name="date" value=""><script>alert('0');</script>" />
    Now you have a script element, which gets interpreted by the browser and leads to the execution of the JavaScript code. See the difference?

    Secondly, cross-site scripting has nothing to do with hidden fields or forms at all. It's a manipulation of the output. It can happen anywhere in the HTML document. The head, the body, in some tag, in an attribute, it doesn't matter. If somebody is able to inject JavaScript there, you have a problem.

    To be honest, I wonder where you're getting at. Lately, you seem to be very interested in somehow reducing security and finding cases where you don't need it. Why? There's no way around security. Unless your site consist of a bunch of plain HTML files with no JavaScript, you have to deal with cross-site scripting, SQL injections and all that other stuff. That's simply a consequence of dynamic websites. You should acknowledge that and execute security everywhere. Don't even think about somehow reducing it. Do you really wanna put your application and data (and possibly the server) at risk just to save a few characters?
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  4. #3
  5. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4123
    if your forms are sticky (ie hold post data from a previous request, with the values persisting due to, for example, an incomplete or invalid value) then the post data that is put into them must be escaped as it's user input.

    Even if it's a hidden input, it's only hidden on your form. Don't forget that the vast majority of attacks will come from other webpages, sending data (either by GET or POST) data to your pages. If you allow the display of any of this data in it's uncleanensed/unescaped/raw form then you have a vulnerability.

    As Jacques1 demonstrated a common way for an attack is to break out of the current context, into the context that is vulnerable and then put the active part of the malicious code. So regardless of where the output is, if it doesn't come from you then it has to be escaped.
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  6. #4
  7. Web Developer/Musician
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Nov 2004
    Location
    Tennessee Mountains
    Posts
    2,408
    Rep Power
    1031
    I concur with both replies. Most attacks are launched not with your forms but with copies of your forms or using a server side http client. I can use php curl to post to any site I wish with any input I wish. Hidden only means hidden when you view the page. Someone can easily view the source of your for form and use those values to post to your site using a very long list of methods.
  8. #5
  9. A Change of Season
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2004
    Location
    Next Door
    Posts
    2,650
    Rep Power
    171
    1 - These 2 seem to be oposit opinions:

    Originally Posted by Northie
    if your forms are sticky then the post data that is put into them must be escaped as it's user input.
    Vs
    Originally Posted by Jaques1
    The value happens to be HTML syntax, but that doesn't matter. It's just data. It doesn't get interpreted as HTML, because it's in a data context, not an HTML context. It's as good or bad as putting "zxcvbnm" in there.
    Yet this seems to be completely harmless:
    html Code:
    <input type = "text" value="<script>alert('jj');</script>" />





    2 - The other thing I like to ask:
    Originally Posted by Jaques1
    html Code:
    <input type="hidden" name="date" value=""><script>alert('0');</script>" />
    How did you end up with such code?
  10. #6
  11. A Change of Season
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2004
    Location
    Next Door
    Posts
    2,650
    Rep Power
    171
    Originally Posted by Hammer65
    Most attacks are launched not with your forms but with copies of your forms or using a server side http client. I can use php curl to post to any site I wish with any input I wish.
    Do you find this form vunrable to that kind of attack (cross-site scripting)?
  12. #7
  13. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,957
    Rep Power
    1045
    Originally Posted by zxcvbnm
    1 - These 2 seem to be oposit opinions:
    Those are two different things:

    Your particular example happens to be harmless, because you simply wrote down an input element with a certain value. You haven't injected any HTML. The value looks like HTML, but it's just data, because it's inside the attribute.

    If this was supposed to be a cross-site scripting example, you simply haven't done it correctly. Your JavaScript code doesn't reach the JavaScript interpreter.

    Trouble begins when you let other people write stuff into the attribute (or your HTML document in general). Because they will try to get out of the attribute and into the HTML context. This is as easy as injecting a double quote, which terminates the current attribute and allows the attacker to create their own attributes or even elements.

    So you must escape the user input (like Northie said). There's no doubt about that, it's a definite fact.

    All I said was that your particular example is no cross-site scripting.



    Originally Posted by zxcvbnm
    2 - The other thing I like to ask:How did you end up with such code?
    This is what people might inject into your document if you let them.

    The highlighted string terminates the current attribute as well as the tag and creates a new script element with JavaScript code in it.



    Originally Posted by zxcvbnm
    Do you find this form vunrable to that kind of attack (cross-site scripting)?
    The input is being properly escaped, so those two fields are not vulnerable to XSS.

    However, filling the password field with the previously submitted value is a huge security risk. First of all, it means that the plaintext password will reside in the HTML document for an indefinite amount of time. Anybody with access to the PC can read the password from the source code.

    It also means that the plaintext password unnecessarily travels all the way back from the server to the client. Since you haven't set up proper TLS encryption on your production site, this is pretty bad.
    Last edited by Jacques1; August 17th, 2013 at 11:01 PM.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  14. #8
  15. A Change of Season
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2004
    Location
    Next Door
    Posts
    2,650
    Rep Power
    171
    Originally Posted by Jacques1
    Trouble begins when you let other people write stuff into the attribute (or your HTML document in general).
    Your HTML document in general I understand BUT write stuff into the attribute Because they will try to get out of the attribute and into the HTML context? How do they do that? How can they get out of double quotes for example:
    html Code:
    <input type = "text" value = "how can I get out of here?" />
  16. #9
  17. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,957
    Rep Power
    1045
    They simply inject a double quote to terminate the current attribute. This gets them into the HTML tag. If they wanna leave that as well, they additionally inject a >:

    Code:
    <input type="text" value=""><strong>I'm out.</strong>" />
    This leads to

    Code:
    <input type="text" value=""> <strong>I'm out.</strong> (some invalid stuff ...)
    Escaping prevents this by marking all special characters like quotes and > as text (via HTML entities). This way they can't be used to break out of an attribute or a tag.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  18. #10
  19. A Change of Season
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2004
    Location
    Next Door
    Posts
    2,650
    Rep Power
    171
    Originally Posted by Jacques1
    They simply inject a double quote to terminate the current attribute. This gets them into the HTML tag. If they wanna leave that as well, they additionally inject a >:

    Code:
    <input type="text" value=""><strong>I'm out.</strong>" />
    This leads to

    Code:
    <input type="text" value=""> <strong>I'm out.</strong> (some invalid stuff ...)
    Escaping prevents this by marking all special characters like quotes and > as text (via HTML entities). This way they can't be used to break out of an attribute or a tag.
    Won't it convert
    html Code:
    <script>alert('h')</script>
    to
    html Code:
     & l t ; script & g t ;alert('h') & l   t  ;/script  & g t ;
    (I had to add spaces as Devshed doesnt let me put it.)
    Last edited by zxcvbnm; August 17th, 2013 at 11:55 PM.
  20. #11
  21. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,957
    Rep Power
    1045
    What do you mean by "it will convert"?

    If you escape the input with htmlspecialchars(), then, yes, all dangerous characters will be replaced with the corresponding HTML entities. That's the whole point of escaping.

    If you don't escape the input, it will stay like it is and may be used for JavaScript injections.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  22. #12
  23. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4123
    Originally Posted by zxcvbnm
    1 - These 2 seem to be oposit opinions:

    VsYet this seems to be completely harmless:
    html Code:
    <input type = "text" value="<script>alert('jj');</script>" />





    2 - The other thing I like to ask:How did you end up with such code?
    By submitting the value
    Code:
    "><script>alert('0');</script>
    To the form

    The first two characters complete the input tag allowing the rest to be treated as HTML - thus the contents of the script tag is executed. The final /> from the original template just becomes some harmless invalid HTML
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  24. #13
  25. Wiser? Not exactly.
    Devshed God 1st Plane (5500 - 5999 posts)

    Join Date
    May 2001
    Location
    Bonita Springs, FL
    Posts
    5,932
    Rep Power
    4033
    If you had code like this:

    Code:
    <input type="text" value="<?=$_POST['field']?>" name="field">
    and I went to your form and in that field I typed the value "><script type="text/javascript">alert('hi');</script>

    then your script would end up generating the output:
    Code:
    <input type="text" value=""><script type="text/javascript">alert('hi');</script>" name="field">
    As you can see there, the script is no longer part of the value attribute and as such it will be executed by the browser. This is how someone would execute a cross-site scripting attack.

    To prevent this, you have to escape your data using htmlspecialchars, htmlentities, or similar. Using those functions, the characters ", <, and > will get properly escaped into &quot; &lt; and &gt; meaning they will not cause a problem when the browser interprets the HTML.

    This code would be ok:
    Code:
    <input type="text" value="<?=htmlentities($_POST['field'])?>" name="field">
    On your sample link, you appears to be properly escaping the data using one of these functions and so there is no issue. If you are not doing it yourself, perhaps some library you are using is managing it for you. Some template engines will automatically escape output variables for example.
    Recycle your old CD's, don't just trash them



    If I helped you out, show some love with some reputation, or tip with Bitcoins to 1N645HfYf63UbcvxajLKiSKpYHAq2Zxud
  26. #14
  27. A Change of Season
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2004
    Location
    Next Door
    Posts
    2,650
    Rep Power
    171
    Originally Posted by kicken
    On your sample link, you appears to be properly escaping the data using one of these functions and so there is no issue. If you are not doing it yourself, perhaps some library you are using is managing it for you. Some template engines will automatically escape output variables for example.
    Yes I use this:
    PHP Code:
    if (!function_exists('html_escape'))
        {
            function 
    html_escape($var)
                {
                    if (
    is_array($var))
                        {
                            return 
    array_map('html_escape'$var);
                        }
                    else
                        {
                            return 
    htmlspecialchars($varENT_QUOTESconfig_item('charset'));
                        }
                }
        } 
    Thank you guys. Great stuff
  28. #15
  29. A Change of Season
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Mar 2004
    Location
    Next Door
    Posts
    2,650
    Rep Power
    171
    About storing these characters into the database.

    I guess it be right to store into database without HTML escaping and HTML escape only when printing. No harm could come from storing html tags into the database.

    I have seen both. I have seen wome phpmyadmin databases where they strore as escaped and some not escaped.
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo