Incident Response Guidelines for Developers

Mistakes will happen and security lapses happen to even the most well-funded organizations. When a security incident does happen it’s important to ensure that a proper response is taken. That means collecting the necessary information about the extent of the issue, notifying interested parties, and reflecting on how this could have been avoided or prevented.

Sensitive Content Exposed to Unauthorized Persons

Access to the admin or the system was not compromised, but areas or specific content on the site was exposed to individuals who were not permitted access to it, either through their own explicit attempts or through faults in the authorization checks in the site.

The content is identifiable by URL

If the content exposed is identifiable by URL, we can utilize web server logs to discover the extent of the problem. We also must identify any leak through search engine crawlers, and close those gaps.

• Search for the content via major search providers and identify if it has been picked up in their results.
• If search engines had reveled content which should not have been public, add appropriate patterns to robots.txt to exclude these areas in the future
• Utilize Google Webmaster Tools, and similar facilities for other engines, to have the existing results cleared
• Search the logs for the extent of the exposure. Over how long was the content accessed? By how many people? Are there usage patterns that can identify how it was found?

The content was leaked by directory listing

Disable directory listing in all cases. See documentation for apache http://wiki.apache.org/httpd/DirectoryListings In nginx the autoindex option is off, by default http://wiki.nginx.org/HttpAutoindexModule

The content was leaked by easily guessable URLs

Do not rely simply on where you link to a resource. Check the permissions of the view when displaying sensitive content. Evaluate adding checksums to URLs, or removing sequential identifiers.

A django debug traceback exposed data

First, disable DEBUG mode immediately in production or public staging machines. If the information included credentials, follow the guidelines below for exposed credentials. To safeguard in the future, utilize Django’s blacklist of parameters to show in tracebacks.

Website Credentials Exposed

Credentials to authenticate on the site were leaked, either in plaintext or hashed, for one or many users, and possibly for users with staff or admin accounts on the website.

User table data was leaked

Any user accounts may be compromised. Initiate a password reset for all accounts.

Further, identify the source of the leak. Was a laptop compromised? Was a backup stored on a cloud service (S3 snapshot of an EBS device, for example) in an insecure way? Identify the cause and apply other steps according to this document.

Asset Credentials Exposed

Credentials were leaked which would allow access by SSH, the AWS API, or other third party APIs which require secret keys that are not normally seen by users. This does not include third party services used from Javascript, where the keys are seen by user clients anyway.

EC2 Key is leaked

In this case, the instance must be rebuilt with a new key. The key is bound to that instance, and cannot be revoked. We should have standard processes in place to rebuild machines, migrate content, and get a new server online quickly. If this is the case, all content and assets on the machine are considered leaked and checklists for all of those situations should be followed, as well.

Server Access is Compromised

Should a server machine be compromised, either via a specific developer’s private key or some previously unknown backdoor, immediate action must be taken. Another user with access must disable the public key for the compromised user and eject any current logins under that name, immediately, to ensure no one can access the machine and that any who may have done so do not remain connected.

First, all logs on the machine must be pulled safely for analysis, so we can learn more about the attack. Pull logs for external services (SSH, HTTP, etc.) to help identify the avenue of entry, and pull logs of all internal services (Postgresql, Redis, etc.) to help identify what steps the intruder may have made after entry into the system.

It is recommended that a replacement server been provisioned and the services migrated to this new machine. If a machine was compromised, it can be difficult or impossible to verify that the intrusion did not leave behind any backdoors or compromise additional resources on the original machine.

Key for third party service leaked

Generate a new key or account on the service and disable the old one. This depends on the service. This is only needed for services with sensitive keys, where the key: - Allows access to sensitive data or content - Allows modification of data - Allows access through a limited quota before being slowed or blocked from user

Users Were Tricked by a Third Party with our Site

There are several forms of this. Click-jacking, Cross-site request forgeries, and insecure redirects are common examples.

An iframe was involved

Block the content from use inside iframes. The X-Frame-Options HTTP header can be used to DENY iframe containing of pages on your site, or to allow only for containing pages from the SAMEORIGIN or to specifically ALLOW-FROM a whitelist of origins. Check the Mozilla docs on X-Frame-Options for a full explaination.

https://docs.djangoproject.com/en/stable/releases/1.4/#simple-clickjacking-protection