12 ms·

Imagine you implement every type of possible security... Keeping your entire server-stack up-to-date, making sure you have SSL, using strong encryption for log

• GuiA 11y ago
  Well, that's why you either have a team of competent people making sure all your stuff is up to date, routinely performing pentests, etc., or you delegate as much as possible of those responsibilities to 3rd parties (e.g. Heroku).
  • electic 11y ago
    Doesn't matter. Eventually, there is a 0-day, that no one knows about, that is used on you.
• Dylan16807 11y ago
  Wrong lesson. Don't put secret keys in your repository. Someone getting a copy of your code should be a big annoyance at worst.
  • stickfigure 11y ago
    Don't put secret keys in your repository is also the wrong lesson. The right lesson is: Know where your secret keys are and take the appropriate steps to secure them. Whether that's in the codebase, a properties/ini/conf/whatever file, environment variables, whatever - know where they are and make sure you understand possible threats against them. This story could just as easily have been written about how easy it is to download ALL_THE_SECRETS.txt. Don't feel smugly secure just because you don't store passwords in git.
    • jsprogrammer 11y ago
      Is there a general algorithm that can tell you all possible threats against your secret keys?
      • lmm 11y ago
        No, there are an infinity of things that shouldn't have access to your secret keys. So you have to take a default deny approach, and ensure that only things that positively should have access to your secret keys do.
      • danudey 11y ago
        My approach to security, when discussing things with our engineers: 1. Make a list of everything that absolutely positively cannot live without this data/access/permissions/etc. 2. Put the data somewhere where absolutely nothing whatsoever can ever read it (except root). 3. Figure out what one single change will resolve #2 so that the things in #1 can happen without any other things gaining access. If you don't do #1, you don't understand your requirements/applications. If you don't do #2, then your data is probably vulnerable through some other mechanism. If you can't do #3 then you probably need to change something else (e.g. stop running all processes as the same user, stop running all services on the same box, stop trusting users, set up more granular sudoers rules, etc). What I find is that when you come up with an idea for #3, and then come up with a list of side effects, you can actually find a lot of the kinds of issues I mentioned above, for example where the public website CMS (as 'daemon') and the accounting backend (as 'daemon') both have access to the same resources, and thus someone gaining access to the CMS can get the accounting DB user/pass and get access to your transaction records, user database, etc.
    • Dylan16807 11y ago
      Putting keys in a text file doesn't fit the narrative of a generally-careful user forgetting about side effects and metadata. It's important to know where your keys are, but it's also important to not store your keys in certain ways that are easily overlooked. A lesson of "don't put secret keys inside the web root" is also useful. But a lesson of "know where your keys are and secure them" is a bit too short-sighted. You don't just want them to be secure right now, you want the mechanisms keeping them secure to be mistake-resistant. Don't put them in the code, even if you promise to be super careful.
  • dangero 11y ago
    Where is the right place to store db passwords, api keys, etc? What is best practice in this area?
    • tfigment 11y ago
      My preferred solution currently is to use try to use encrypted strings in config files that are not stored in VCS. The host machine encrypts and decrypts using host specific keys so if the file is copied off-server, it is not fully compromised immediately. This is usually via python script which rewrites the file. (BTW, pretty easy to do on Windows boxes with MS API). I've considered using encrypted folders on windows in addition but not sure if that really makes a difference. Usually the base config is in VCS but without user/password/db strings. We then manually configure the file with the encrypted strings on the server (usually with the machine name in the filename so that we can use hostname in code to find it and makes it clear the file is machine specific). Not all tools make this easy though and only works if you can add your own code in between. Also prefer files to environment as the files can be locked down easier in my opinion and more obvious what is going on. I like some of the other solutions that are using encrypted strings but with a keystore server and may consider for the future if they support both windows and linux.
    • craigkerstiens 11y ago
      http://12factor.net http://12factor.net provides a good guidance for this at a high level. In reality all config should be separated from code. There's a variety of mechanisms for loading this into your environment.
    • crdoconnor 11y ago
      http://docs.ansible.com/ansible/playbooks_vault.html http://docs.ansible.com/ansible/playbooks_vault.html
    • cddotdotslash 11y ago
      I use AWS for a number of applications, so I've started doing the following: 1. Create a JSON file containing encrypted secrets (DB pass, etc.) 2. Upload the file to a secure S3 bucket with fine-tuned permissions and server-side encryption 3. For the instance that is launching, include the permission in the IAM role that allows it to "S3:GetObject" on the specific JSON file you uploaded. 4. Deliver decryption keys to the app in some manner (Chef, Ansible, etc.) 5. When the app starts, it downloads the JSON file and loads the environment variables. I wrote a blog post[1] about this with more detailed info and an NPM module if you use Node.js. [1] http://blog.matthewdfuller.com/2015/01/using-iam-roles-and-s3-to-securely-load.html http://blog.matthewdfuller.com/2015/01/using-iam-roles-and-s...
• totony 11y ago
  A good practice is to disable features that you don't use. I don't think many people need their hidden files to be remotely accessible, so maybe they should either remove the permissions or set a flag in their server so it doesn't allow downloading them.
• ejcx 11y ago
  I did a conference talk at derbycon on exactly this, regarding startups. The amount of obvious holes of founders not knowing what XSS is, or writing bad PHP apps with obvious code execution vulns, or glaring logic and auth mistakes allowing full account hijacks is incredible. It's really bad out in AppSec land
  • RowanH 11y ago
    Link to your talk ?
    • ejcx 11y ago
      It was my first conference talk. If you would like to ask any questions email me at the one in my profile https://m.youtube.com/watch?v=wzrVYyouQTk https://m.youtube.com/watch?v=wzrVYyouQTk
  • tracker1 11y ago
    Hell, I recently saw an application where there was unchecked input for being able to download files outside the application... if you passed it a path of, for example `../../somefoo-file` would take you out of that application's path.
    • ejcx 11y ago
      This is called either a Local File Inclusion or a Directory Traversal Vulnerability. The name depends on the details. It's really really common, and definitely something I see a lot of. The OWASP Top 10 is deadly.
• Negitivefrags 11y ago
  This is the asymmetric nature of security in general. You only need to make a single mistake and you are hosed. Your attacker can fail an arbitrary number of times and only needs to succeed once. If you are 99.9% likely to make the right call on anything that could have a security impact then you only need to make 1000 decisions before you probably screwed one up and have a hole. Some would say this means true security is impossible.
  • deleted 11y ago
    [deleted]
  • err4nt 11y ago
    As humans are fallible, it's inevitable we will make mistakes carrying out even what we intend to do, when we know it and are actively trying to do the right thing. Sometimes our mistakes are not recognizing the right thing to be done, or not recognizing anything at all. I think the view that true security is impossible is true if security is up to one person. What about a system with multiple layers of sign-off, or an automated system that can help test the security of what you're doing and alert/prevent dangerous behaviour without specific reasons.
• vog 11y ago
  You seem to imply this is a novel attack vector. But it's really just an instance of a very old mistake: Don't use the root of your app as document root! It's really as simple as that. Almost all modern apps have a subdirectory "public/" or similar. That one is meant to be used as document root. You only have to ensure there are no sensitive files in there. If you fail to introduce such a directory, you'll have a game of cat-and-mouse, where you have to add extra webserver rules for each sensitive file: VCS, crypto secrets, private keys, and so on. In that setup it's easy and very likely to forget one. Of course, this then creates the feeling of "How can anybody keep track of this never ending list of security details?" In the end, this is a blacklist vs. whitelist thing. Like with your firewall, you want one rule that blocks everything and allows only specific stuff. The alternative is to allow for everything, have rules to deny all sensitive stuff, and finally get in trouble for having forgotten one rule (e.g. probably because an additional service was introduced after the firewall rules have been written.)
  • juliangregorian 11y ago
    Great point. How much do you want to bet most of these are PHP, where it takes special discipline not to make your top directory web-accessible?
    • TazeTSchnitzel 11y ago
      Does it? If you're on a shared host with just the one directory, maybe. But if you are configuring your own server, you still point it to htdocs and keep the config below it.
    • pmx 11y ago
      It takes very little effort in php. You simply have your index.php and any public assets in the document root and then use index.php as a bootstrap to bring up your application. Everything else goes outside of the document root.
      • deleted 11y ago
        [deleted]
• dschiptsov 11y ago
  What "all vital user-data and admin data"?
• flihp 11y ago
  This is what makes security hard: To attack successfully you only have to find one significant mistake, to defend successfully you can't make any mistakes.