2 ms·

Well.. it's not so hard to avoid this kind of bugs. In web applications the basic rules are the following: - Use something able to auto-escape SQL queries, unl

by antirez 19y ago

Well.. it's not so hard to avoid this kind of bugs. In web applications the basic rules are the following: - Use something able to auto-escape SQL queries, unlike things done at hand like with PHP mysql_escape_string() - Check user input _a lot_ for sanity. Write utility functions to access get/post vars able to make sure data type and range are ok, like, getintparam("foo") or if you aspect a value between 1 and 10 getintparam("foo",1,10). Similar functions with strings where you can specify the valid set of chars are also helpful. - Remember to output html entities not only when you are outputting text, but also in html tag attributes like foo="bar". "bar" requires to be converted in HTML entities of course. - Create a solid authentication scheme, for example write in the user table a 256bit authentication random number got from /dev/urandom, and set it as user cookie. - When there are load problems use HMACs to "sign" important data and store it in user's cookies. It's possible to check for integrity of the data without to access the DB at all. Fast & Safe. - Remember that if a user is logged in, an external site can have code like img src="http://yoursite/op.cgi?delete=all http://yoursite/op.cgi?delete=all" To avoid this attack make sure to: 1) use HMAC-ed IDs for importante objects. "ff83729A2" instead of "41". Require that IDs of objects target of operations or other auth tokes the external site can't guess are required in order to perform operations. 2) for very important operations the system may require the user to type the password. - Make sure you are not using algorithms with some worst case time complexity that can be triggered from outside. It will be very easy to turn this into a DOS. And... of course: wirte simple code that's simple to check for corner cases. Computers aren't currently able to audit code, so you need to optimize for humans even for security.

tuukkah 19y ago
You provide a good list of features to remember to implement, I didn't know of HMACs for example. I was thinking more about the process though: Are startups able to review all their code for bugs before pushing it online? When you code long hours, do you still write down all your assumptions to allow for audits later? What if none of the founders have experience in network security? When you don't have formal and clear processes in place, how easy is social engineering among customers?
- antirez 19y ago
  Actually to handle security is very hard. I think startups usually can't handle security as a process because time is little, stress in implementing features high and so on, so the best founders can do is probably to have security-aware programmers and try to don't introduce too much bugs. Then if/when you become a mainstream site start doing planned security auditing from time to time.
mdakin 19y ago
For more information about making data tamper-proof using HMACs see the paper "Dos and Don'ts of Client Authentication on the Web" by Kevin Fu et al. [1]. I've implemented the "FuCookie" and I use it everywhere. [1] http://pdos.csail.mit.edu/papers/webauth:tr.pdf http://pdos.csail.mit.edu/papers/webauth:tr.pdf
natrius 19y ago
"Remember that if a user is logged in, an external site can have code like img src="http://yoursite/op.cgi?delete=all http://yoursite/op.cgi?delete=all"" You shouldn't be using GET for anything that has side effects.
- antirez 19y ago
  Good point, but with ajax this is very common. There are also frameworks that abstract "params" into GET+POST+COOKIES, since they are all under user control in theory the security level is the same, but actually the img trick changes this.
- tuukkah 19y ago
  You probably know this, but the same is applicable to "cross-site request forgeries" in general, they just aren't as trivial to exploit as img src. If they can perform a GET they can perhaps use javascript to import confidential information into a loaded page and scrape that. POST requests aren't safe from tricks by third-party sites either, as is mentioned here for example: http://www.owasp.org/index.php/Cross-Site_Request_Forgery http://www.owasp.org/index.php/Cross-Site_Request_Forgery (Open Web Application Security Project looks interesting otherwise too.)

by antirez 19y ago

tuukkah 19y ago

You provide a good list of features to remember to implement, I didn't know of HMACs for example. I was thinking more about the process though: Are startups able to review all their code for bugs before pushing it online? When you code long hours, do you still write down all your assumptions to allow for audits later? What if none of the founders have experience in network security? When you don't have formal and clear processes in place, how easy is social engineering among customers?

antirez 19y ago
Actually to handle security is very hard. I think startups usually can't handle security as a process because time is little, stress in implementing features high and so on, so the best founders can do is probably to have security-aware programmers and try to don't introduce too much bugs. Then if/when you become a mainstream site start doing planned security auditing from time to time.

mdakin 19y ago

For more information about making data tamper-proof using HMACs see the paper "Dos and Don'ts of Client Authentication on the Web" by Kevin Fu et al. [1]. I've implemented the "FuCookie" and I use it everywhere. [1] http://pdos.csail.mit.edu/papers/webauth:tr.pdf http://pdos.csail.mit.edu/papers/webauth:tr.pdf

natrius 19y ago

"Remember that if a user is logged in, an external site can have code like img src="http://yoursite/op.cgi?delete=all http://yoursite/op.cgi?delete=all"" You shouldn't be using GET for anything that has side effects.

antirez 19y ago
Good point, but with ajax this is very common. There are also frameworks that abstract "params" into GET+POST+COOKIES, since they are all under user control in theory the security level is the same, but actually the img trick changes this.
tuukkah 19y ago
You probably know this, but the same is applicable to "cross-site request forgeries" in general, they just aren't as trivial to exploit as img src. If they can perform a GET they can perhaps use javascript to import confidential information into a loaded page and scrape that. POST requests aren't safe from tricks by third-party sites either, as is mentioned here for example: http://www.owasp.org/index.php/Cross-Site_Request_Forgery http://www.owasp.org/index.php/Cross-Site_Request_Forgery (Open Web Application Security Project looks interesting otherwise too.)