This post does not make you hacker overnight, or by this you cannot hack a website, this is not a shortcut to become a security tester. This article is purely for helping individuals in building secured applications.
If you are from infosec, you might be tired of listening to people asking, is application good to go live, can I push my code to production? Below are some of the easy steps for developers for developing a secured application and this would reduce efforts and time of security team on vulnerability assessment and penetration testing. It is always advised to have a proper code with certain validation and verification.
a) Don’t hardcode credentials: Credentials should not be saved within the application. To some extent it might be useful during development stage but strongly advised not to be saved within the application code.
b) Store Database Credentials Securely: The credentials must be stored in a centralized location as a separate database for which authentication is required.
c) Error handling on invalid credentials: Error Messages on invalid credentials for authentication must be clear and must not reveal any sensitive data against username enumeration or other available fields.
d) Account lockout against bruteforce attacks: Account lockout policy needs to be implemented to safeguard against brute force attacks for both the login and forgot password features. The account should be locked for a certain period of time say 24/48 hours or until manually unlocked from the application support
e) Browser memory: Credentials should not be retained in browser memory after logout. The credentials should be encrypted with base64 or any secured hashing mechanism.
a) Access control checks: Make sure that there is a separate mediatory between different privileges with a principle of common security assistance on the application.
b) Least Privileges: Users of an application should not provide root access instead minimal privileges could be given. If not explicitly allowed then access should be denied.
c) Don’t use direct object references: Do not allow direct referencing to any files or parameters that can be manipulated to grant access to the resources. Privileged access should be assigned based on individual user identity.
d) Validated redirects: An attacker can get access to private content without authentication, if redirection are not validated properly.
3. Input Validation and Output Encoding (Text Fields)
a) Output Encoding: All output operations must contextually encode data before displaying it on browser.
b) Set Encoding in the Application: For every page in your application set the encoding using HTTP headers or meta tags within HTML. This ensures that the encoding of the page is always defined and that browser will not have to determine the encoding on its own.
c) Prefer White-lists Over Blacklists: All the input fields should have input validation. White listing input is the preferred approach. Data that meets a certain criteria must be accepted.
d) Tokens against Forged Requests: Applications must embed random token that is not known to third parties into the HTML form for preventing CSRF (Cross-Site Request Forgery) attacks. This CSRF protection token must be unique to each request. This prevents a forged CSRF request from being submitted because the attacker does not know the value of this random token.
e) File Uploads: While accepting files from the user make sure to validate the size of the file, the file type, the file-name, the file contents and where is it going to save as well as ensuring that it is not possible to override the destination path for the file.
f) Parameterized SQL Queries: SQL queries should not be created dynamically using string concatenation. Similarly, the SQL query string used in a bound or parameterized query should never be dynamically built from user input.
g) Terminate/abort invalid inputs: This is a safety and final strategy on unaccepted characters that occur as input, but if implemented poorly it might lead to Denial Of Service attack in which attacker can flood the system with unexpected inputs, forcing the system to expend scarce processing and communication resources on rejecting it.
4. Session management
a) Session fixation: Session tokens must be changed during login and must have different tokens for logged in and logged out states.
b) Session variables invalidation: Session variables should be invalidated in the server after logout or session timeout after a certain period of idle session.
c) Unique session variables: Session variables must be unique and should not be reused for different accounts.
d) Strong session variables: Session variables should be random and must be of certain length which is not easily guessable by the attacker.
e) Secure cookie variables: Usage of secure cookie attributes i.e., Httponly and Secure Flags. The cookies should be set to exact domain and path and the cookies should not be shared with other sub domains.
5. Communication Protocols
a) SSL: Clear text protocols such as HTTP is always prone to MITM (Man In The Middle) as an attacker can intercept requests in the network level hence SSL is recommended during authentication and post login pages.
b) Disable HTTP: Resources accessible on secured channel such as HTTPS must restrict access with clear text protocols such as HTTP
c) Salted passwords: Passwords must be stored using a secured algorithm and iteratively hashing with a random salt added to hash makes more stronger to crack
d) SSL Certificates: SSL certificates used must be from a reputed CA signed with secure exchange keys and ciphers.
a) Maintain logs on all privileges: This includes all authentication activities, all privilege changes, administrative activities, access to sensitive data.
b) Secure your logs: Logs are to be saved carefully and maintained on a secure server against tampering to avoid from loss and logs should be maintained for a specific duration according to industry policies.
c) Improper logs: Maintaining appropriate logs and storing them are the important part of logging management. Sensitive information should not be part of logs and the entire log needs to be encrypted in certain situations.
7. Reset password
a) Once reset password link is used, link should be expired for the next use.
b) Till the user resets password, the previous password should not be disabled.
c) Even if the link is unused the reset password link needs to be expired within a defined time say 48 or 72 hours.
d) Reset password link should be over an SSL
e) Old/previous password reset link should be expired once new password link is generated.
f) Token used in reset password link should be mapped to the users email ID and should not be used to reset password of another user.
g) Token should not be sequential or easily guessable or a short one. It should be minimum of 16 characters so that it is not easily brute forced.
h) Password policy should be maintained on reset password page.
8. Error Handling
a) Generic error messages: Display generic error messages to the user, error messages should not reveal details about the application like technology used, internal IP or path, and stack-overflow errors.
b) Framework related errors: All framework generated errors must be generic or messages can be customized so that sensitive information about the framework is not revealed.
c) Unhandled exceptions: Exceptions are strictly advised to handle errors either at client or server side. It is good to have ‘finally’ code block for all unhandled errors with generic error message.