According to Microsoft, it is not possible to design and build a secure Web application until you know your threats. After you know your threats, design with security in mind by applying timeworn and proven security principles. As developers, you must follow secure coding techniques to develop secure, robust, and hack-resilient solutions. The design and development of application layer software must be supported by a secure network, host, and application configuration on the servers where the application software is to be deployed.
Threats, Vulnerabilities, and Attacks
A threat is any potential occurrence, malicious or otherwise, that could harm an asset. In other words, a threat is any bad thing that can happen to your assets.
A vulnerability is a weakness that makes a threat possible. This may be because of poor design, configuration mistakes, or inappropriate and insecure coding techniques. Weak input validation is an example of an application layer vulnerability, which can result in input attacks.
An attack is an action that exploits a vulnerability or enacts a threat. Examples of attacks include sending malicious input to an application or flooding a network in an attempt to deny service.
To summarize, a threat is a potential event that can adversely affect an asset, whereas a successful attack exploits vulnerabilities in your system.
Securing your application
If you were to review and analyze the top security issues across many Web applications, you would see a pattern of problems. By organizing these problems into categories, you can systematically tackle them. These problem areas are your application's vulnerability categories. The categories are as follows;
How do you know that the input that your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing. The applications should be robust against all forms of input data, whether obtained from the user, infrastructure, external entities or databases.
Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password. This section deals with authentication issues associated with secure web apps, such as basic/digest authentication, form-based authentication, integrated (SSO) authentication, etc.
Authorization is how your application provides access controls for resources and operations. This section addresses authentication issues, ensuring a user has the appropriate privileges to view a resource. Topics such as principle of least privilege, client-side authorization tokens, etc. are addressed here.
A session refers to a series of related interactions between a user and your Web application. Session management refers to how your application handles and protects these interactions. It goes ahead to address issues such as authenticated users having a robust and cryptographically secure association with their session, applications enforcing authorization checks and applications avoiding or preventing common web attacks, such as replay, request forging and man-in-the-middle.
This section helps to ensures that cryptography is safely used to protect the confidentiality and integrity of sensitive user data. How are you keeping secrets, secret (confidentiality)? How are you tamper proofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity.
This section addresses application issues so they are secure from well-known parameter manipulation attacks against common interpreters. Form fields, query string arguments, and cookie values are frequently used as parameters for your application. Parameter manipulation refers to both how your application safeguards tampering of these values and how your application processes input parameters.
When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?
Auditing & Logging
This section deals with designing well-written applications that have dual-purpose logs and activity traces for audit and monitoring. This makes it easy to track a transaction without excessive effort or access to the system. They should possess the ability to easily track or identify potential fraud or anomalies end-to-end.
This section is focused on creating secure web applications which are as well-built and secure out-of-the-box as possible. Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Configuration management refers to how your application handles these operational issues.
Application security checklist
- Ensure your application properly encodes or escapes data prior to exchanging it with external components such as a database, LDAP server, web browser, etc
- Reduce the surface area of attack. Ask yourself how you will contain a problem. If an attacker takes over your application, what resources can he or she access? Can an attacker access network resources? How are you restricting potential damage? Firewalls, least privileged accounts, and least privileged code are examples of compartmentalizing.
- Ensure you encrypt sensitive information such as authentication credentials, sensitive customer data, etc. prior to transmitting such information across the network
- Run processes using accounts with minimal privileges and access rights, you significantly reduce the capabilities of an attacker if the attacker manages to compromise security and run code
- Ensure your application uses thread-safe techniques to protect against race conditions that could harm system availability and/or data integrity
- Your application's user input is the attacker's primary weapon when targeting your application. Assume all input is malicious until proven otherwise, and apply a defense in depth strategy to input validation, taking particular precautions to make sure that input is validated whenever a trust boundary in your application is crossed.
- Verify the origin of sensitive requests through the use of unpredictable, unique nonce as hidden input form values.
- Most importantly, ensure that your application fails gracefully and securely without divulging details of the underlying implementation to the end user.
- Ensure your application performs access control checks in a consistent manner across all potential execution paths
- Last but as well important, if you do not use it, remove it or disable it. Reduce the surface area of attack by disabling or removing unused services, protocols, and functionality. Does your server need all those services and ports? Does your application need all those features?