3 ms·

That is basically injecting JS to trigger XSS (running user's code on the application)

ohmaigad 6y ago
Your description about the issue is sketchy, there is nothing wrong with disabled input fields but it it sounds like you are making that an issue while the actual issue would be parsing those fields in the backend.
- introvertmac 6y ago
  Maybe I was not able to make it clear - what I meant was "if you can inject arbitrary code in disabled fields and the system is using those JSON data elsewhere, it can lead to injection attacks" The whole idea is validate the user inputs - be it disabled fields or normal inputs
  - wruza 6y ago
    It is more “sanitize” than “validate” then. Saying that you need to sanitize disabled or normal fields in “crypto websites” is like saying that you need to put handrails on 7th floor of a red building to prevent falling down. But in reality you may fall from any height that has no handrails, and 7th floor and a red decoration aren’t specific requirements for falling. I’m not trying to nitpick here, my confusion was genuine. These sorts of statements are hugely misleading even for seasoned folks (“what if I missed something in disabled inputs? why crypto suffers from that?”), and in novice developers it creates magic recipe thinking instead of generic awareness that you never want to execute(user_input).
    - introvertmac 6y ago
      You made a good point but accepting JS in a currency field requires validation + sanitization. Validate for functional errors then sanitize for injection issues. Hope it makes more sense now! Sorry for any confusion from previous comments or post
wruza 6y ago
I still don’t get it. Some code may use .value, store it, parse it, send as a part of a form, etc. How is that a security issue? If you meant that evaluating strings (as in eval(s) or el.innerHTML = s) is dangerous, then okay, but why this exact location - disabled inputs? One can eval(from_any_source) if they are unaware.

Your description about the issue is sketchy, there is nothing wrong with disabled input fields but it it sounds like you are making that an issue while the actual issue would be parsing those fields in the backend.

introvertmac 6y ago
Maybe I was not able to make it clear - what I meant was "if you can inject arbitrary code in disabled fields and the system is using those JSON data elsewhere, it can lead to injection attacks" The whole idea is validate the user inputs - be it disabled fields or normal inputs
- wruza 6y ago
  It is more “sanitize” than “validate” then. Saying that you need to sanitize disabled or normal fields in “crypto websites” is like saying that you need to put handrails on 7th floor of a red building to prevent falling down. But in reality you may fall from any height that has no handrails, and 7th floor and a red decoration aren’t specific requirements for falling. I’m not trying to nitpick here, my confusion was genuine. These sorts of statements are hugely misleading even for seasoned folks (“what if I missed something in disabled inputs? why crypto suffers from that?”), and in novice developers it creates magic recipe thinking instead of generic awareness that you never want to execute(user_input).
  - introvertmac 6y ago
    You made a good point but accepting JS in a currency field requires validation + sanitization. Validate for functional errors then sanitize for injection issues. Hope it makes more sense now! Sorry for any confusion from previous comments or post

wruza 6y ago

I still don’t get it. Some code may use .value, store it, parse it, send as a part of a form, etc. How is that a security issue? If you meant that evaluating strings (as in eval(s) or el.innerHTML = s) is dangerous, then okay, but why this exact location - disabled inputs? One can eval(from_any_source) if they are unaware.