3 ms·

There is one thing client side js does protect you against very well and that is simple sql-injection style vulnerabilities. Any database exposure vulnerabilit

by tinco 14y ago

There is one thing client side js does protect you against very well and that is simple sql-injection style vulnerabilities. Any database exposure vulnerability that does not compromise the host is fully mitigated by client side encryption. This is a very large class of vulnerabilities in the real world, so this is actually a very good case in favor of client side encryption.

tptacek 14y ago
Uh, what? Losing the database is game over. The odds are very high that by losing the database loses command execution on the server.
- tinco 14y ago
  Well that depends entirely on wether you've configured your environment securely. If your sql server runs as an unprivileged user preferably on a different machine this should not be an issue.
  - tptacek 14y ago
    Uh huh.
    - tinco 14y ago
      So you obviously don't agree, care to elaborate? You seem to be the expert here.. (btw I don't mean that command execution is not a problem, I mean that if you configure your sql server well it should not allow command execution, there's not _that_ many ways to escape the database..)
      - tptacek 14y ago
        This is one of those discussion where when I point out mistakes that (a) everyone makes and (b) you haven't thought of before and (c) are exploitable whether or not you encrypt, you're going to say "oh, well, you just shouldn't make those mistakes", and so I'm not interested in pursuing this and am content to rest my case.
  - patio11 14y ago
    Even if someone were impressively thoughtful about that, they'd still cough up arbitrary code execution on the web tier for most Rails / Django applications, by writing an appropriately serialized external command into the queuing system. That external command would be loading metasploit into /tmp and then gaining root with a local privilege escalation. Thomas is right, though: if you lose the DB, you're forked.
wglb 14y ago
>There is one thing client side js does protect you against very well and that is simple sql-injection style vulnerabilities. Um, I don't think so. Client side JS is very good at doing SQLi. How on earth does client-side encryption mitigate against SQLi?

by tinco 14y ago

tptacek 14y ago

Uh, what? Losing the database is game over. The odds are very high that by losing the database loses command execution on the server.

tinco 14y ago
Well that depends entirely on wether you've configured your environment securely. If your sql server runs as an unprivileged user preferably on a different machine this should not be an issue.
- tptacek 14y ago
  Uh huh.
  - tinco 14y ago
    So you obviously don't agree, care to elaborate? You seem to be the expert here.. (btw I don't mean that command execution is not a problem, I mean that if you configure your sql server well it should not allow command execution, there's not _that_ many ways to escape the database..)
    - tptacek 14y ago
      This is one of those discussion where when I point out mistakes that (a) everyone makes and (b) you haven't thought of before and (c) are exploitable whether or not you encrypt, you're going to say "oh, well, you just shouldn't make those mistakes", and so I'm not interested in pursuing this and am content to rest my case.
- patio11 14y ago
  Even if someone were impressively thoughtful about that, they'd still cough up arbitrary code execution on the web tier for most Rails / Django applications, by writing an appropriately serialized external command into the queuing system. That external command would be loading metasploit into /tmp and then gaining root with a local privilege escalation. Thomas is right, though: if you lose the DB, you're forked.

wglb 14y ago

>There is one thing client side js does protect you against very well and that is simple sql-injection style vulnerabilities. Um, I don't think so. Client side JS is very good at doing SQLi. How on earth does client-side encryption mitigate against SQLi?