think about security problems which will affect the site once the firewall is down

[cgolubi1]

Once we go to beta, we will not be firewalling access to HTTP (we'll probably stop firewalling alpha as well at that time, to avoid discouraging alpha-testers and spending time maintaining the ACLs). Once we drop the firewall, we'll be exposed to a lot of doorknob-rattlers and spiders (benign and malicious, but universally dumb). What bad things might happen at that point? Figure out what we should be most worried about which would be easiest to make small changes to prevent, and do so.

[cgolubi1]

In case it wasn't obvious, i'd like some brainstorming here.

Some things i've thought of (other than the tickets i already filed):

• The javascript UI is the most obvious weakness, since it's less of a clear bottleneck for access than responder is. Most of the pages shouldn't allow unauthenticated users to do things, but some will. Thinking about it right now, a refactor that only exposes unauthenticated users to a much simpler subset of the UI code, and refuses to load most of the .js files for them, could be a win. But that would be a big refactor --- i think we have to assume that anyone can load any of the .js code, and do a basic sanity-audit of it. How do we do that? What problems should we be looking for?
• responder and dummy_responder are the second set of weak points --- we should look for obvious bugs within those, and within the functions they call which are accessible to unauthenticated users. That gets unauthenticated users pretty far down into the tree of PHP functions, and as in the JS case, the functions unauthenticated users can access live in the same files as functions which implement the meat of the site (e.g. BMInterface), so we can't really claim there's a bright line there. So, again, we want a basic sanity-audit of PHP code. How do we do that? What problems should we be looking for?
• Rate-limiting: locking users out after three password attempts sounds un-fun (because it's a lot of work for us to deal with unlocking legitimate users). Configuring the API so that if you mistype your password, you can't try again for three seconds, would probably take care of bots (for whom three seconds per attempt is expensive), and be relatively harmless for users (for whom three seconds isn't that long). Along similar lines, i made a python script last night to create some games for me, and realised that it would be super easy for a legitimate user with a buggy script to create 100000 games before they noticed the problem, and make a cleanup headache for us. If it were easy to do some sort of "responder will only allow a given unauthenticated IP or logged-in user to make N calls in M seconds" thing, i feel like that would pay a lot of dividends. We might be able to exempt calls that are really read-only, but we should be conservative in figuring out which those are.
• Improved logging to detect problems: i have a script that e-mails me the error log contents, but it's gotten flooded with failing to look up images and failing to load buttons with wildcard dice. We need to shut up or fix those known problems, or i need a better script (probably the latter), so that if something is actually amiss, i'll know about it.

Any other thoughts, or modifications to my thoughts? We can't do everything we think of here for the beta, but i'd like to hit the most egregious things, to reduce headaches at unexpected times later.

[AdmiralJota]

• Regarding the javascript UI code: if the API is locked down appropriately, then what are the dangers of letting any users have full access to the javascript files? I'm not sure I'm seeing any, unless someone is trying to do some clever cross-site attacks against users.
• For the responder, I don't know how things are implemented, but presumably there is something on the server that looks at the "type" parameter in the POST in order to decide which method to call. It makes sense to me that there should be a test right there to see whether the user is authenticated or not, and for it to refuse to call any methods outside of the special whitelist (login, create user, verify) at all if they're not. Also, careful attention should be paid not only to what's allowed to happen within those unauth-available functions, but also in any code that gets called before we reach the point where unauthorized users are cut off. Is there any way a cleverly constructed request could make something unexpected happen, whether by overflowing something, passing an unexpected or invalid value, passing unexpected parameters, or anything else?
• Hmm. When you mention doing a "responder will only allow a given unauthenticated IP or logged-in user to make N calls in M seconds" thing, what makes an IP authenticated vs. unauthenticated? Wouldn't anyone be able to have a buggy script, authenticated or not? Also, if you do something like this, I hope it's done in a way that's bot-friendly in terms of how it reacts to excessive requests (e.g. with a JSON reply in the usual format with appropriate "status" field, rather than a custom JSON format or a bare HTTP error).
• Are things set up in a way that you can classify different error levels (warnings, minor errors, normal errors, ack the world is about to end errors) and filter them appropriately before emailing?

[cgolubi1]

On logging: as part of #642, i excluded a bunch of known-harmless things from my script that greps the apache error log. Now it's back to showing real errors again, so that's probably good enough for now on that front.

[cgolubi1]

Offhand comment: i keep coming back to the question of whether we're handing chat reasonably, but i actually think we are --- we're encoding chat for user viewing by setting the jQuery "text" attribute in the td in which we place the chat. The point of the text attribute is that it encodes everything as text, not as HTML. Under the hood, per http://api.jquery.com/text/, jQuery text() uses DOM createTextNode(), which seems to in fact be an approved safe way to excape stuff for rendering as text, see e.g. http://shebang.brandonmintern.com/foolproof-html-escaping-in-javascript/. I'm not saying this is foolproof, but in fact, i think this is The Right Way To Do it, and i don't actually need to worry about this issue again until we're doing forum-y stuff and trying to allow links within posts.

[cgolubi1]

So, i did some reading/thinking, and at a high level, the things i think are dangerous right now fall into the general categories (some of these are bigger than others):

• Attacks against users' browsers by malicious attackers via the site UI (all of these fall into the general category of "XSS prevention"):
  • javascript should validate data sent by the backend more (at all) carefully, in case someone can forge/modify the unauthenticated response from the backend
  • look over everything i do with user-provided input in javascript --- if i'm using that stuff blindly in tags or attributes, it's a vulnerability
  • in particular, carefully validate stuff Env.js parses from the easy-to-munge location bar
  • if i were still worried about XSS attacks in malicious chat messages, this is where i'd mention that, but, per previous comment, i'm currently not
• Attacks against the backend:
  • responder should validate data sent via POST more (at all) carefully, and make sure it doesn't have any weird characters before shoving it into database queries
  • responder should validate API cookies more (at all) carefully, and make sure they don't have any weird characters before shoving them into database queries
  • Consider adding some protection against cross-site request forgery about whether we want to protect against cross-site request forgery. This is a slightly obscure attack, but it also looks like the "Synchronizer Token Pattern" defense would be quite easy to implement.

Which if any of those are worth doing anything about in the near-term? Still thinking.

[blackshadowshade]

I don't know exactly the details of this issue, but I would try to answer the question: "What's the worst that could happen?"

[jl8e]

Those are the major attack classes.

XSS: If the back-end is safe, then the front end shouldn’t need to re-check. If the back end’s been subverted, then everything it’s serving to the client is presumptively malicious, including the JS that’s supposed to check.

There should be a consistent policy of either sanitizing text for HTML entities either always on DB insertion, or always before sending it back to the user. I believe (I am in no way an expert here) that sanitizing before sending back is better:

• If a hole in the sanitizing is found, you don’t need to scrub the entire database.
• If you ever need the DB’s contents in a non-HTML context, the quoting doesn’t get in the way. (Probably a minor concern, especially for this site.)

While you’re probably right that your approach with the chat messages is safe, I’d be inclined to scrub them server-side anyway, just to have a consistent policy.

SQL injection: As long as all the SQL queries are parameterized, injection’s not a threat, no matter what weird characters are in the user-provided data.

If we’re using PDO, then there’s a catch, in that it apparantly fakes prepared statements on MySQL by default, though this is configurable. Here’s the fist link I dug up that contains how to fix that: http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php

CSRF: it's an issue, but there’s a relatively small amount of damage that can be done.

[cgolubi1]

I created #674, #676, #677, and #678 for various security-related issues noted in this ticket. We definitely want to do an XSS/CSRF push, to be good browser citizens, but we don't think it's needed for the alpha.

Relisting this ticket itself as beta now.

[AdmiralJota]

Does the site still use unsalted hashes for passwords? If so, I strongly recommend salting them. If our database was ever exposed (e.g., if there were an exploit in the forum software we used), then it would be easy to recover passwords from an unsalted hash using a rainbow table. And just warning users not to re-use important passwords won't mean they won't do it anyway.

[cgolubi1]

First off, i'm pretty sure we do salt our hashes. Second off, since multiple people have now mentioned breaking password hashes here, i'd like to caution against worrying too much about this --- i know it's very traditional advice to assume an attacker can get their hands on our encrypted password database and try to crack passwords, but, really: we send passwords unencrypted, we don't limit password-guessing attempts, we don't think we're very secure against browser-side XSS/CSRF-type games. People are going to get at user accounts using one of those methods.

Maybe they can also exploit our code bugs to execute arbitrary code on the server, grab our password database, and crack it offline. But the nice thing about AWS is that we're protected by their firewall, through which the only non-HTTP protocol we're allowing is SSH from a limited range of IPs using public keys only. So if they want onto the box, they're going to have to go through the webservice to get there. And, i mean, they might well. But i don't think it's the optimal way to specifically get at user passwords by grabbing our custom database format --- other things are so much easier and less dependent on our particular site/codebase.

IMO, worrying about cracking encrypted password tables is worrying about the wrong thing.

[blackshadowshade]

So, can we close this one?

[cgolubi1]

I think the gist of https://github.com/buttonmen-dev/buttonmen/issues/627#issuecomment-37131634 is that we'd like to do a push of looking for XSS issues, and haven't done so yet, nor made a separate ticket for it.