Security considerations for user authorization in applications

1. There exists a clearly defined matrix defines access permissions on resources by different user roles and processes.
2. Access to sensitive and system resources is restricted to selected roles only.
3. Authorization is based on Windows authentication
4. The system uses ACLs (in addition to other) techniques for authorization.
5. The system uses application-level, (in addition to other) techniques for authorization.
6. The system uses code access level (in addition to other) techniques for authorization. (e.g.. CAS in dot net)
7. The authorization mechanism of the application achieves from organizational changes and movements e.g.. Richard is in one role today, another tomorrow. In tomorrow's role he is less privileged than today's.
8. Identity information is passed without specific protection from one part of the application to the other, only if the sender and the receiver reside in trusted zones.
9. Identity information is passed by signing/encrypting from one part of the application to the other, if the sender and the receiver reside in non-trusted zones.
10. Authorization has been performed in the UI tier such that controls are hid/shown based on user authorization. If this is true check the following: the logic for the above is consolidated in a single section of the design documents. Where the behaviour of a control is consistent across pages, a repeater control is used.
11. The MVC pattern is used for the application.
12. If the number of roles is less and/or if the pages for each role differ to a large extent then separate UI should be created.
13. Authorization has been performed in the UI tier such that flow of UI is changed based on type of user
14. Authorization has been performed in the UI tier such that access to the entry page of the app is configured for authorized users only.
15. Authorization has been performed in the UI tier such that authorization check is carried out each time a new page is loaded.
16. Authorization has been performed at the business logic.
17. Authorization has been performed at the database level.
18. Access to database tables and other entities is being controlled using SQL Data Definition Language such as GRANT, DENY and REVOKE.
19. The database rules are being used to enforce security and authorization.
20. The architecture takes into consideration that no more data is read other than what is required to be displayed to the user.
21. All operations that perform a business process are authorized.
22. Authorization functionality is encapsulated as utility classes. (This will obviate the need for non-security minded programmers from having to learn too much about authorization)
23. Guards are present to ensure that sensitive data cannot propagate outside the data tier.
24. "If the authorization logic is simple, checks are being made in stored procedures.
25. If the authorization logic is complex, checks are being made in data access logic components and call SPs."
26. If an authorization cache is being used then it is protected by encryption (for confidentiality) and is signed (to prevent tampering)

Security considerations for session management in applications

1. Authentication cookies are protected in transit by using SSL
2. The contents of authentication cookies are encrypted.
3. A session timeout has been factored in the design of the application
4. Session ids generated for tracking sessions should not be guessable numbers (e.g.. First user who visits the site gets session no. 1, the second user gets 2 and so on.)
5. Session ids are not reused for a long cycle.
6. Design supports an elaborate mitigation for session hijacking attacks.
7. Use one session token with two values during authentication. One value before authentication and one after.
8. The system does not rely too much on persistent cookies
9. Guards are present for confidentiality and integrity of cookies.
10. Are sensitive cookies marked as "secure"
11. Does the application rely on IP filtering for security?

Security considerations when auditing and logging in applications

1. The design has a standardized approach to exception handling across the application.
2. In the case of an exception minimum amount of information is returned to the user.
3. Lowest level exceptions are encapsulated into a relevant exception for the benefit of the above tiers of the application. (For e.g.. Instead of telling that a certain row/column of the database could not be accessed, it is better to inform a plain "access denied")
4. Where user actions are being logged, private data should not be written to the log. (e.g.. Changed passwords, critical settings etc.)
5. The key parameters to be logged and audited have been identified.
6. The application has levels of auditing and logging.
7. Application logs have been protected from tampering.
8. Application logs have been protected from unauthorized access.
9. Utilities have been factored in for interpretation of log files.

Security considerations when handling sensitive data

1. All data along with their criticality have been identified.
2. A matrix indicating the data and the means to secure it is available in the design document.
3. All data required to be kept confidential is encrypted.
4. All data that absolutely must not be tampered is digital signed using private key or using HMAC.
5. Private information (secrets) is not persisted to disk until necessary.
6. Private information (secrets) is kept in memory for only as longs as it is necessary.
7. Private information (secrets) are not stored as literal values in code (no hard-coded values)
8. Database connection information such as user name and password are not stored in plaintext on disk.
9. No sensitive data is stored in persisted cookies.
10. No custom-built algorithms are being used to encrypt data.
11. If standard algorithms are being used, then the library used to implement them are tested sufficiently. (Watch out for algos like AES, RSA etc. implemented by local app teams)
12. If standard algos are being used, there is a documented rationale for chosen key sizes.
13. The encryption key is stored in a secure manner.
14. There is a provision in the application for changing the keys used for encryption.
15. There is a provision in the application for rolling over data (i.e. data encrypted with "old" key to be re-encrypted using "new" key)
16. There is a provision in the application for handling scenarios like "lost key", "lost password to key" and "key compromise"
17. Sensitive data is not transmitted using GET, as it can be directly seen in the browser address bar.
18. Sensitive information is not being sent in the HTTP headers as these can be easily changed.
19. Audit logs are encrypted (if required) , but should be definitely be protected against tampering and loss of integrity.
20. Where possible, WS-Security or SSL/TLS is used to protect ephemeral data rather than implement crypto schemes out of primitives.
21. For .NET code, System.Security.Cryptography namespace will be used.
22. For Java code, JCE providers will be used (Bouncycastle or SunOne)
23. For C/C++ code CryptoAPI (CSP) will be used
24. For scripting, CAPICOM will be used
25. For Windows kernel mode, statically linked version of RSA32.LIB will be used."
26. The crypto algorithm being used will be easily replaceable. Hard coding is not being done. It is easy to upgrade the algorithms in the future.
27. If the user of the software does not specify it, strong algorithms are used by default. The software will not "automatically" fall back to a weak crypto.
28. If symmetric key-based cryptography will be used, then the CBC mode will be used.
29. If hash functions will be used, then the SHA-2 family of hash functions (SHA-256, SHA-384 or SHA-512) will be used.
30. The application will DP API (Data Protection API) to store secure data and passwords.
31. If the application requires random numbers, a strong quality random number generator will be used.
32. If a secret key is required to be generated from a user password, the user password should not be merely hashed. Instead a KDF (Key derivation function) should be used to derive a key from a password. (Eg. CryptDeriveKey on Windows)
33. Are cache-control : no-cache or cache-control : no-store used to prevent caching in browser?
34. Application caters if 128-bit SSL is not supported in the web browser.

Windows registry application security best practices

Use the following appsec best practices when dealing with the Windows registry.

1. Use of registry reduces application portability. Therefore, use only if required.
2. Don’t use the registry as a configuration trash–bin.
3. Don’t store secrets in registry.
4. Encrypt application data stored in the registry.
5. Discourage users from directly editing the registry.
6. Perform input validation on data read and written to registry.
7. Don’t write data to HKLM. Reading back the data will require the user to be logged on as administrator as by default only Read-access is provided to HKLM all users.
   
8. Don't open registry keys for FULL_CONTROL or ALL_ACCESS.

List of security regulations to comply applications to

There are the following regulations that applications have often to comply to:

1. International Standard - ISO 17799
2. California AB 1950 and SB 1386 - Personal Information Privacy
3. Children's Online Privacy Protection Act of 1998
4. Director of Central Intelligence Directive series
5. Regulation E - Electronic Fund Transfer
6. General - EU Directive Applicability
7. Federal Information Security Management Act (FISMA)
8. The Gramm-Leach-Bliley Act (GLBA) - Act of 1999
9. The Health Insurance Portability and Accountability Act (HIPAA) of 1996
10. International Standard - ISO 27001
11. Japan's Personal Information Protection Act
12. MasterCard Site Data Protection Program (SDP)
13. North American Electric Reliability Council (NERC) Critical Infrastructure Protection Committee (CIPC) Security Guidelines for the Electricity Sector
14. OWASP 10 Most Critical Web Application Security Vulnerabilities
15. Payment Card Industry Data Security Standard (PCI)
16. Personal Information Protection and Electronic Documents Act (PIPED Act)
17. The Privacy Act of 1974
18. Safe Harbor
19. SANS Top 20 Internet Security Vulnerabilities
20. Securities Exchange Act of 1934
21. Sarbanes-Oxley Act of 2002
22. Title 21 Code of Federal Regulations (21 CFR Part 11) Electronic Records
23. UK Data Protection Act 1998
24. Visa Cardholder Information Security Program (CISP)
25. WASC Web Security Threat Classification
26. BASEL II

Temporary Files Security In-depth

Introduction
Many applications require to create and maintain temporary files. Often these temporary files are created without the enduser knowing about the same. Security attacks realized due to insecure temporary file management is a critical category of security attacks on software applications. Application developers are required to follow certain security best practices when creating temporary files. In this article I shall discuss these best practices.

Vulnerabilities due to poor tmp file implementations
Attack#1
victim.c:
filename = mktemp(template);
fd = open(filename, …);

But an adversary can create a file with the same name between the two statements.
Then, victim.c will either end up opening the adversary’s file, or will fail to create the temporary file itself.

Attack#2 Symbolic Link Vulnerability
If the attacker knows where the application creates its temporary files and can guess the name of the next temporary file, the following attack can be realized:
- Attacker will put a symbolic link at the temporary file location.
- The attacker will link the symbolic link to a privileged file.
- Now, the application will unknowingly write to the privileged file instead of writing to the file in the temp directory.

Security Considerations when designing Temporary File modules
1. Avoid temporary files altogether
Temporary files often end up creating more problems than solving them. The effort (time/money) required to develop a temporary file management module often outweighs the features that get added to the application.

2. Reasearch the platform support for temporary files
Before starting out to code the temporary file generation module, assess the existing support for file generation on the target platform. For example, Windows has the GetTempPath() API call that provides the default temporary directory path.

3. Ensure file name uniqueness
The filename of the temporary file must be unique. This ensures that the application does not end up clobbering any existing data on the disk. If a file having the same name already exists on the disk, the logic of file name generation should generate (see next point) a new file name and use that instead.

4. Ensure file name randomness
When generating the file name of the temporary file ensure that the name is not guessable. Typically, the default APIs that are supplied by the operating system for generating temporary files create filenames containing monotonically increasing integers. Therefore it becomes possible to predict the filename of the next temporary file that the application will generate. Use cryptography to generate unique file names. For eg. the CryptGenRandom() function may be used to achieve this.

5. Ensure proper permissions for the temporary file
Ensure that the temporary file have the appropriate ACLs (access control lists) set on them. Avoid publically writable temporary directories if possible. If using a publically writable directory, make a directory within the publically writable directory for temporary files, with read and write permissions for the application only. Temporary files are often used to hold intermittent state information about the operation in progress and may contain confidential information.

6. Ensure secure cleanup of temporary files after usage
One of the most common attacks on applications that use temporary files is the recovery of previously deleted temporary files from the disk. This is trivially possible with the help of software available on the Internet. In order to mitigate against this operation, shred temporary files. Depending on the sensitivity of the information contained in the temporary file, ensure that the cleanup is commensurate with the security levels desired.

7. Prevent covert access
Sometimes the application's temporary files containing sensitive information may be indexed by the underlying Operating System service that may be active on the user system. For example, the indexing service on Windows, when active, silently builds an index of all files on disk. It is possible that sensitive information will end up getting indexed so that a malicious user may use the Search Files/Folders feature to obtain application intelligence.

8. Dont use dangerous functions for temporary file generation
Dont use mktemp(), tmpnam(), tempname(), tmpfile() for generating temporary files. Also don’t reuse the parameter in mkstemp(f) in any other function call, such as stat(), chmod(), etc because the same name may refer to a different file.

9. Avoid storing very sensitive information in temporary files
As a rule, avoid storing sensitive information in temporary files. This is a very common reason for most attacks on applications. An application may employ sophisticated security safeguards such as encryption for securing its data but between encryption may be unwittingly storing sensitive information to an unprotected temporary file. Avoid this at all costs.

10. Rely on absolute file paths and file handles
When building the file paths of the temporary file, use absolute paths. Do not use relative file paths. Also, if the directory path where the temporary files are being housed is being accepted from the user, ensure that it has been sanitised. To prevent time-of-check-to-time-of-use (TOCTOU) attacks, ensure that you use file handles (and not file paths) for future access to the temporary files. Many a vulnerability have been imputed to applications using relative file paths for temporary file access.

11. Securely create temporary files
If open() is being used to create a temporary file use the O_CREAT|O_EXCL flags. If the Windows CreateFile() is being used to create a temporary file use the CREATE_NEW attribute. Calling the APIs with these flags ensures that these APIs fail if a file is already present with the same name in the temporary directory.

Conclusion
Temporary files are sometimes very useful for the application developer. However, improper implementation of temp file modules leads to the realization of several attacks on the application. The application developer must use the techniques contained in this article to mitigate against these security issues.

When to consider cryptography in your application

Cryptography DOES provides the following services to applications:
a) Confidentiality
Prevents application from being read and disclosed to everyone except for the intended recipient. This is achieved using encryption.

b) Authentication
Provides techniques using which the sender of a message (or originator of the data) can be authenticate reliably. This is achieved using message digesting and encryption.

b) Integrity
Provides a tamper-detection and tamper-evident technique for detecting if the message has been tampered since it was first generated. This is achieved using HMACs and digital signatures.

c) Non-repudiation
Provides a means for preventing an entity from denying an operation was carried out by that entity by providing conclusive proof. This too is achieved using digital signatures.

d) Replay protection
Provides techniques that can be used to prevent a previous message from being replayed to recreate the desired operation. This is done with a combination of message digesting and timestamps.

Cryptography DOES NOT provides the following services to applications:
a) Denial of service protection
Cryptography represents an operation carried out on data. It does not (and cannot) prevent DoS attacks.

b) Preventing Eavesdropping
c) Providing access control