Improving Web Application Security: Threats and Countermeasures
Examine how your application handles sensitive data in store, in application memory, and while in transit across the network. Table 5.5 shows the most common vulnerabilities that are associated with handling sensitive data.
| Vulnerability | Implications |
|---|---|
| Storing secrets when you do not need to | This drastically increases the security risk as opposed to not storing the secret in the first place. |
| Storing secrets in code | If the code is on the server, an attacker might be able to download it. Secrets are visible in binary assemblies. |
| Storing secrets in clear text | Anyone who can log on to the server can see secret data. |
| Passing sensitive data in clear text over networks | Eavesdroppers can monitor the network to reveal and tamper with the data. |
Use the following questions to help validate the handling of sensitive data by your application:
-
Do you store secrets?
-
How do you store sensitive data?
-
Do you pass sensitive data over the network?
-
Do you log sensitive data?
Do You Store Secrets?
Secrets include application configuration data, such as account passwords and encryption keys. If possible, identify alternate design approaches that remove any reason to store secrets. If you handle secrets, let the platform handle them so that the burden is lifted from your application wherever possible. If you do store secrets, review the following questions:
-
Can you avoid storing the secret?
If you use an alternative implementation technique, it could remove the need to store secrets. For example, if all you need to do is verify that a user knows a password, you do not need to store passwords. Store one-way password hashes instead.
Also, if you use Windows authentication, you avoid storing connection strings with embedded credentials.
-
How do you store secrets?
If you use encryption, how do you secure the encryption keys? Consider using platform-provided DPAPI encryption that takes care of the key management for you.
-
Where do you store secrets?
Examine how your application stores its encrypted data. For maximum security, access to the encrypted data should be restricted with Windows ACLs. Check that the application does not store secrets in clear text or in source code.
If you use the Local Security Authority (LSA), the code that retrieves the secret has to run with administrator privileges, which increases risk. An alternative approach that does not require extended privileges is to use DPAPI.
-
How do you process secrets?
Examine how your application accesses the secrets and how long they are retained in memory in clear text form. Secrets should generally be retrieved on demand, used for the smallest amount of time possible, and then discarded.
-
Do you store secrets in cookies?
If so, make sure the cookie is encrypted and is not persisted on the client computer.
How Do You Store Sensitive Data?
If you store sensitive application data, such as custom credit card details, examine how you protect the data.
-
What encryption algorithm do you use? You should encrypt the data using a strong encryption algorithm with a large key size , such as Triple DES.
-
How do you secure the encryption keys? The data is only as secure as the encryption key, so examine how you secure the key. Ideally, encrypt the key with DPAPI and secure it in a restricted location, for example, a registry key.
Do You Pass Sensitive Data Over the Network?
If you pass sensitive data over the network, check that the data is either encrypted by the application or that the data is only passed over encrypted communication links.
Do You Log Sensitive Data?
Examine whether or not your application (or the host) logs sensitive data such as user account passwords in clear text log files. You should generally avoid this. Make sure the application does not pass sensitive data in query strings because these are logged and are also clearly visible in the client's browser address bar.
Категории