26

I can't find anything in the documentation about val() and prop() and escaping.

Are they intended to escape values when used as setters?

Matt Fenwick
  • 48,199
  • 22
  • 128
  • 192

3 Answers3

29

Not really. .val() is used to set a form field's value attribute, so escaping isn't really necessary there. You'll be setting the value via the DOM, so it's not like you're constructing HTML through string concatenation. .prop(), on the other hand, doesn't even interact with attributes at all - just DOM properties, so you don't need to working about HTML escaping their either.


Edit: for the sake of clarification, I'm assuming that you're asking this because you're concerned about .prop() or .val() as an XSS attack vector (or just an opportunity to shoot yourself in the foot)? If that's the case, you need to remember that when setting attributes and properties via the DOM, the values that you set are essentially sandboxed to the attribute or value you were interacting with. For example, given the following:

<div id="foo"></div>

And you attempted to abuse an attribute value, such as:

$('#foo').attr('rel', '"></div><script>alert("bang");</script><div rel="');

You might be concerned that this would result in something like the following:

<div id="foo" rel=""></div><script>alert("bang");</script><div rel=""></div>

This will never happen, though. You will indeed have a rel attribute with the evil-looking string as its value, but no new markup or DOM nodes will be created. The string itself isn't escaped - it's just simply not interpreted as markup. It's just a string and that's it.

jmar777
  • 38,796
  • 11
  • 66
  • 64
  • 2
    So setting the `value` of an element to `evil"string` could *never* cause any problems? – Matt Fenwick May 15 '12 at 15:53
  • 3
    Correct - any danger would be downstream from that, with regards to what you do with the value after you've retrieved it from the element. This is also assuming that you're setting it via `.val()` or other DOM API backed method. I just expanded my answer with some clarification. – jmar777 May 15 '12 at 15:59
  • @jmar777 Is it the same for jquery .attr() method for setting the src of an image? i.e $("#profile_pic").attr('src', profile_image); do I need to worry about encoding variable profile_image here? when i do try to encode it using ESAPI encodeForHTMLAttribute() it doesnt work anyway so im guessing i don't need to? thanks – Sarah Nov 28 '16 at 20:15
  • @Sarah that is correct, there's no need to encode there. The value assigned to the src attribute won't be interpreted as markup. – jmar777 Nov 30 '16 at 20:03
  • @jmar777 Thank you. and one more related question. what if instead of using jquery .attr() I am preparing the img html with string concatenation and inserting the image url as follows: '' .... ? apparently you can "break out" of the attribute with certain special characters. should I then use encodeForHTMLAttribute()? thanks – Sarah Nov 30 '16 at 20:09
  • 1
    @Sarah Sorry for the delayed response, but *yes, be very careful with generating HTML via string concatenation*! That is absolutely an XSS attack vector if care isn't taken with encoding. I'm not familiar with `encodeForHTMLAttribute()` (looks like that's a ColdFusion utility?), but I recommend reading further on that topic here: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes – jmar777 Dec 17 '16 at 19:23
8

They expect strings, not HTML. You don't need to escape anything.

The methods themselves don't do any escaping either, the underlying DOM APIs they use also deal in strings, not HTML.

Once you start using JavaScript you almost never need to worry about HTML syntax, the only exception I can think of is when dealing with the innerHTML property which explicitly deals with (de)serialising the DOM to and from HTML.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • It's probably worth clarifying that the underlying DOM API's don't really escape anything either. When you're setting attribute and property values, you're not creating new markup or DOM nodes or anything of that sort, so escaping is sort of a non-issue. – jmar777 May 15 '12 at 15:50
  • @Quentin. Is it the same for jquery .attr() method for setting the src of an image? i.e $("#profile_pic").attr('src', profile_image); do I need to worry about encoding variable profile_image here? when i do try to encode it using ESAPI encodeForHTMLAttribute() it doesnt work anyway so im guessing i don't need to? thanks – Sarah Nov 28 '16 at 20:15
0

I just want to add that you DO have to worry when inserting values inside attributes with side effects which can cause code execution. These include image src attribute which can be used for xss. See: https://www.owasp.org/index.php/Script_in_IMG_tags

Guy L.
  • 153
  • 1
  • 9