6 ms·

> The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing. Confused here. Where were input va

> The old app that I wrote would happily take JavaScript or SQL snippets as inputs to any text field and do The Right Thing. Confused here. Where were input validation checks in your implementation? How did you guard against SQL injection, etc?

Winsaucerer 4y ago
Presumably they just did whatever the standard provided mechanisms for their SQL driver were (such as parameterised queries). User inputs text in a comment box, and you insert it into database using such a mechanism and it's safe. And if you're using, for example, Go's templating library, then it automatically escapes everything in HTML templates unless you explicitly override this default behaviour.
- paulryanrogers 4y ago
  Well if it was only 100 lines of plain JS then how would one guard against reflection attacks? I.e. submitting HTML (like script tags) then getting that to render when others view the tainted data.
  - Winsaucerer 4y ago
    Because on this way of building sites, the user submitted data is escaped before it reaches the browser. E.g.: https://go.dev/play/p/MmNSxU5QfAb https://go.dev/play/p/MmNSxU5QfAb (hit run to see the output). The JS wouldn't need to do any escaping, because it's not trusted to handle any unescaped data. It's operating on the already-escaped html template.
    - skeeter2020 4y ago
      They certainly weren't using Go, or as stated, any framework. Also no mention of any type of web server; not sure what magical code was creating dynamic HTML from the database. Where was the business logic? Stored Procedures? No mention of more dynamic functions... No integrations... Sure sounds like a desktop browser-only app while the majority of the world today wants some mobile functions from almost every system. There is a lot information, which is understandable but also conveniently supports a very unflattering narrative while simultaneously promoting the OP's awesomeness.
      - Winsaucerer 4y ago
        I think you're reading them far too strictly. I don't think they literally meant they were using nothing beyond JUST the SQL Server and then somehow getting HTML out of that, with 100 lines of JS on top. Unless I misread, I don't see anything that implies they weren't using something like PHP or ASP, for example.
    - P5fRxh5kUvp2th 4y ago
      To me this is the hilarious part. Q: "how do they use the workarounds needed to secure the more complex approaches?" A: "those security concerns don't exist in the approach, no workaround needed. That's part of the simplicity". It just represents a fundamental misunderstanding, but it's not their fault, they've never seen anything else. Like someone using a JWT instead of a session cookie.
      - eurasiantiger 4y ago
        >Like someone using a JWT instead of a session cookie Those aren’t mutually exclusive, you know.
thow232329 4y ago
Just put the queries in procedures with parameters. Only store the procedure calls in your backend, disable arbitrary queries completely in your database permissions.

Winsaucerer 4y ago

Presumably they just did whatever the standard provided mechanisms for their SQL driver were (such as parameterised queries). User inputs text in a comment box, and you insert it into database using such a mechanism and it's safe. And if you're using, for example, Go's templating library, then it automatically escapes everything in HTML templates unless you explicitly override this default behaviour.

paulryanrogers 4y ago
Well if it was only 100 lines of plain JS then how would one guard against reflection attacks? I.e. submitting HTML (like script tags) then getting that to render when others view the tainted data.
- Winsaucerer 4y ago
  Because on this way of building sites, the user submitted data is escaped before it reaches the browser. E.g.: https://go.dev/play/p/MmNSxU5QfAb https://go.dev/play/p/MmNSxU5QfAb (hit run to see the output). The JS wouldn't need to do any escaping, because it's not trusted to handle any unescaped data. It's operating on the already-escaped html template.
  - skeeter2020 4y ago
    They certainly weren't using Go, or as stated, any framework. Also no mention of any type of web server; not sure what magical code was creating dynamic HTML from the database. Where was the business logic? Stored Procedures? No mention of more dynamic functions... No integrations... Sure sounds like a desktop browser-only app while the majority of the world today wants some mobile functions from almost every system. There is a lot information, which is understandable but also conveniently supports a very unflattering narrative while simultaneously promoting the OP's awesomeness.
    - Winsaucerer 4y ago
      I think you're reading them far too strictly. I don't think they literally meant they were using nothing beyond JUST the SQL Server and then somehow getting HTML out of that, with 100 lines of JS on top. Unless I misread, I don't see anything that implies they weren't using something like PHP or ASP, for example.
  - P5fRxh5kUvp2th 4y ago
    To me this is the hilarious part. Q: "how do they use the workarounds needed to secure the more complex approaches?" A: "those security concerns don't exist in the approach, no workaround needed. That's part of the simplicity". It just represents a fundamental misunderstanding, but it's not their fault, they've never seen anything else. Like someone using a JWT instead of a session cookie.
    - eurasiantiger 4y ago
      >Like someone using a JWT instead of a session cookie Those aren’t mutually exclusive, you know.

thow232329 4y ago

Just put the queries in procedures with parameters. Only store the procedure calls in your backend, disable arbitrary queries completely in your database permissions.