Protect Data and Privacy It helps to protect our data inside a database. Sensitive data like passwords, credit card details and bank account details etc. should be stored in encrypted or hashed format inside a database or chosen data storage. One should not use encryption and hashing interchangeably, as encryption and hashing are entirely different from each other. Encryption is used to convert readable text or plain text into unreadable text or cipher text. Encryption is a two way data conversion technique, meaning data which is encrypted can also be decrypted (if you have the decryption key). Encryption can be done in two main ways:
Symmetric method
Asymmetric method
Symmetric encryption or Secret Key Cryptography (SKC) uses a secret key for encryption and decryption. It means the receiver uses same key that was used for encryption to decrypt. Asymmetric method or Public Key Cryptography (PKC) uses two sets of keys to perform encryption and decryption. One is a public key and another is a private key. Public Key is used for data encryption and Private Key is used for data decryption. Depending upon your application requirement, developers can choose between the two encryption methods.
Hashing is different from encryption; unlike encryption, it is a one way process. It means data that’s converted into hashed format can never be converted into plain text.
An application cannot choose hashing or encryption just like that. A ecure storage technique is chosen depending upon the data that has to be stored securely.
At some time in the future, if the sensitive data is to be shown to the user in plaintext, then encryption is the best option (plaintext <->ciphertext).
If the sensitive data is to be stored for some validation or authentication or verification, then hashing should be stored (Plaintext -> Hash).
For example:
Sensitive information between the client and server should also be in encrypted form. Hyper Text Transfer Protocol Secure (HTTPS) should be used instead of Hyper Text Transfer Protocol (HTTP) whenever any sensitive information is to be transmitted. When HTTPS is used, client server communication is encrypted using supported technology like SSLv2, SSLv3, TLS1.0, and TLS1.2. It is especially used to protect highly confidential data like online banking. The port number for HTTP is 80 and for HTTPS is 443. Implement Logging and intrusion Detection In an application, most requests are received using GET, POST, PUT, and DELETE methods. A request sent can be either a malicious request or a clean request. Malicious requests are those requests which contain attack vectors like SQL Injection, XSS, Unauthorized Data Access, etc. When there is public user activity or Intranet employee access, then the application should always keep track of all the activities taking place. Logging is very important in every application and one of the areas which is most neglected during development and deployment. Logging means storing log data about every request that is sent and received, such time, IP address, requested page, GET data, and POST data of a request. If a user is authenticated, then who is the user, when he logged in, when he logged out, etc. Since all user activity is being logged, it should also be noted that user sensitive data like password and financial details should NEVER be logged. Intrusion Detection means a malicious request with an attack vector has been detected and received by the application or not. If such a request has been received, then suitable actions like logging and request drop should be performed. For example, if a SQL Injection vulnerability exists on a login page, the application should have a feature to detect when SQL Injection is performed and should log time and from which IP address the attack originated, and then perform a suitable action on it. ModSecurity and OWASP ModSecurity Core Rule Set Project can prove to be of great use when you want to detect and/or prevent any malicious activity. Logging and intrusion detection is necessary to keep a record of every activity that takes place on an application. Intrusion detection is implemented along with logging to keep a check on when an attack or malicious data is received, so that it can be handled properly. Leverage Security Features of Frameworks and Security Libraries When developers start developing any application, either they don’t implement secure coding practices or use third party libraries for implementing security features. But most programming languages or development framework have built-in security functions and libraries which can be leveraged to implement security features in applications. Developers should use those built-in features instead of third party libraries. Recall OWASP Top 10 Vulnerabilities “A-9 Using Components with Known Vulnerabilities”. If third party components or libraries are used and any vulnerability is discovered in those components, then our application will automatically become vulnerable. It is recommended that developers should use security features provided by the programming language like escapeHtml() of httputils provided by Apache Commons Lang in Java and htmlentities() in PHP, which can be used to mitigate Cross-Site Scripting (XSS) vulnerability. But it is a known fact that industry tested security features are not readily available in programming languages. In such a case where useful and required security features or libraries are not available in the programming language you are using, then industry trusted and tested security libraries should be used. One of the well-known OWASP projects for this purpose is the OWASP ESAPI Project, which helps developers to implement security controls in their applications. For example: In Java we have security functions like escapeHtml() which can be used to mitigate XSS. PreparedStatement is used to mitigate SQL Injection. Using built-in security features ensures that you don’t have to use unnecessary libraries you are not confident in or have security tested. Include Security-Specific Requirements When a software or web application development is to be started, then software requirements are laid out, which takes place in the early stage of an SDLC. As software requirements are mentioned initially in any project, security requirements should also be mentioned. Security requirements, if being made part of an SDLC, can help in implementing security inside the application and also identifying the key areas which can be exploited. According to OWASP Proactive Controls, three security requirements are important:
Security features and functions;
Business logic abuse cases;
And data classification and privacy requirements.
Security features and function All security details, such as application features, modules, database details, modules functioning and security implementation in modules should be mentioned in an application. It should be defined that all secure coding practices in any application should be implemented at the time of development. Business logic abuse cases When any application is designed, there is a way to access data and to perform operations. For example, when a user is performing an online banking transaction, some details are required within a well-defined process:
Login to bank account.
Choose your account to transfer from.
Choose amount and destination account to transfer to.
Enter profile password.
Enter OTP password received on registered phone number.
Confirm transaction.
Wait for success message.
All these steps define a data flow diagram or business logic. Now these details can have some weaknesses, which can make them vulnerable. When the business logic has been listed, key areas of weakness can be identified, and areas where security can be beefed up can be identified too. For example:
User should not be able to choose someone else’s bank account as source account of transfer.
User should not be able to bypass profile password requirement.
OTP should be valid only once and for that account only.
Data classification and privacy requirement Data classification and requirement should be decided at the time of development. When any application interacts with the user, then user data is received and stored. The answers to these questions should be decided in advance:
Which data is to be accepted from the user?
Is that data sensitive or not?
Is that data to be stored?
If data is sensitive, then should the application decide if it will be stored in encrypted or hashed format?
If bank details are stored, then those details should be verified and validated by the application. Data authorization should also be decided at an initial stage, like who can access, delete and modify data. Since the application will be dealing with users and operations on user data. It is critical to maintain logs for all activities. Logging of activity was discussed above in the “Implement Logging and Intrusion Detection” section. Security Design and Architecture In the last one to nine OWASP ProActive Controls, we saw how to implement security in our code, which areas to secure, how to secure and what components can be used to help you implement better security in your application. In the last ProActive Control, we discuss the other areas of application security which can prove to be of great use and should not be neglected. OWASP has defined three key areas to take care of when developing any application:
Know Your Tools
Tiering, Trust and Dependencies
Manage the Attack Surface
Know Your Tools Every application is built using some server side language, client side language, database or no database, etc. Each component used could be the source of opening a security vulnerability in your application and server. For example, using an outdated version of Struts Framework can lead to a user exploiting remote code execution on it, or an older version of PHP leading to the same consequence. Similar is the case for databases and every other component which is used to build an application. So before starting any application development, it should be made clear what components can or may lead to a vulnerable application in the present or near future. Tiering, Trust and Dependencies Each layer of the whole application is called a tier. With each tier there is an associated level of risk and vulnerabilities that can crop in. For every tier — be it client side, server side, database, or anything — the risk associated with it should be calculated, and necessary mitigations should be implemented. When an application is interacting with user input and user data, trust is the only factor which decides which operation should be performed, when to perform, and on what to perform. An authentication page not implemented properly will have a poor trust level and will allow malicious users to access others’ data. In the worst case, it will result in a user transferring funds or accessing confidential company data without proper authorization. Application development involves using several components all together and making sure that each component will work with others. This is the case of dependency, where X component depends upon Y component for its proper functioning. It is very common to use older components to maintain reliability and proper functioning. But each dependency should be thoroughly checked, or else it can create an unwanted weakness inside the application. Manage Attack Surface The attack surface is the whole combined application including software, hardware, logic, client controls, server controls. Everything from physical, digital, to logical makes the attack surface. Any part of a setup if and when found to be vulnerable can act as an open entry gate for a malicious user to perform an action. Developers are usually not concerned about the web server software version the application will be deployed on. But older web server software like Apache or Struts can lead to an attacker successfully exploiting it and managing his/her way into the application and user data. Conclusion From OWASP ProActive Controls we learned how an application can be secured and how to identify the key areas of every application that can all together help in strengthening our application and stored data. OWASP ProActive Controls are a good place to start training developers to implement secure coding practices and beef up the security of key areas of an application like authentication, authorization, user data access and storage. But ProActive Controls should not be looked upon as the only set of controls for application security. It is a good place to start developing skills and knowledge leading to continuous learning and habitual secure coding practices. Reference https://www.owasp.org/index.php/OWASP_Proactive_Controls
