Security-Guide-For-Developers | Security Checklist

Safety Checklist


Authority System (Registration/Registration/Secondary Verification/Password Reset)

    1. Use HTTPS everywhere.
    2. Use Bcrypt to store password hash (necessary to use salt - this is what Bcrypt does).
    3. Destroy the session ID after logging out.
    4. Destroy all active sessions after password reset.
    5. OAuth2 authentication must include the state parameter.
    6. After the login is successful, it cannot be directly redirected to the open path (need to check, otherwise it is easy to have a phishing attack).
    7. Parses javascript://, data://, and other CRLF characters when parsing user login/login input.
    8. Use secure/httpOnly cookies.
    9. When OTP authentication is used on the mobile device, OTP (One Time Password) cannot be returned directly when the generate OTP or Resend OTP API is invoked. (usually by sending a mobile phone to verify SMS, mailbox random code, etc., instead of direct response)
    10. Limit the number of API calls such as Login, Verify OTP, Resend OTP, and generate OTP for individual users, and use Captcha to prevent brute-force attacks.
    11. Check the token of the reset password in the email or SMS to ensure randomness (cannot be guessed)
    12. Set the expiration time for the password reset token.
    13. After the reset password is successful, the token used to reset will be invalid.


    User data and permission checking :


    1.  Resources such as my shopping cart, my browsing history, etc., must check if the currently logged in user has access to these resources.
    2. Avoid resource ids from being traversed successively. Use /me/orders instead of /user/37153/orders to prevent you from forgetting to check permissions, resulting in data leaks.
    3. Modifying the email/mobile phone number function must first confirm that the user has authenticated the email/phone as his own.
    4. Any upload function should filter the file names uploaded by users. In addition, for universal reasons (rather than security issues), uploads should be stored on top of cloud storage such as S3 (handled with lambda) instead of being stored in Your own server to prevent code execution.
    5. The personal avatar upload feature should filter all EXIF ​​tags, even without this requirement.
    6. The user ID or other ID should use the UUID of the RFC compliant instead of an integer. You can find the implementation of the language you are using from github.
    7. JWT (JSON Web Token) is great. It is used when you need to build a single page application/API.


     Android and iOS APP :


    1. The salt of the payment gateway should not be hard-coded
    2. Secrets and auth tokens from third parties should not be hard-coded
    3. APIs called between servers should not be called inside app
    4. Under Android, carefully evaluate all applied permissions
    5. In iOS systems, use the system's keychain to store sensitive information (authorization token, api key, etc.) Do not store this information in the user configuration
    6. Strongly recommended certificate binding (Certificate pinning)


     Security header information and configuration :


    1. Add CSP header information to slow down XSS and data injection attacks. This is important.
    2. Add CSRF header information to prevent cross-site request forgery (CSRF) attacks.At the same time, add the SameSite property to the cookie.
    3. Add HSTS headers to prevent SSL stripping attacks.
    4. Add your domain name to HSTS preload list.
    5. Add X-Frame-Options to prevent clickjacking.
    6. Add X-XSS-Protection to mitigate XSS attacks.
    7. Update DNS records, add SPF records to prevent spam and phishing attacks.
    8. If your Javascript is hosted on a third-party CDN, you need to add an internal resource integration check. For added security, adding require-sri-for CSP-directive will not load resources without SRI.
    9. With a random CSRF token, the business logic API can be exposed as a POST request. Do not expose the CSRF token through the http interface, such as the first request for an update.
    10. Do not use critical data and token in the get request parameter. Exposing server logs also exposes user data.


     Filter input :


    1. All input to the user's parameters should be filtered to prevent XSS attacks.
    2. Use parameterized queries to prevent SQL injection.
    3. Filter all functional user input, such as CSV import.
    4. Filter some special user input, such as using robots.txt as your username, and you've just provided a url such as coolcorp.io/username to provide the user info access page. (It will become coolcorp.io/robots.txt and may not work).
    5. Do not manually assemble the JSON string yourself, no matter how small the object is. Please use the appropriate library or framework for your language.
    6. Filtering inputs that are a bit like URLs to prevent SSRF attacks.
    7. Filter output information before the output is displayed to the user.


    Operating :


    1. If your business is small or you lack experience, you can evaluate the use of AWS or a PaaS platform to run the code.
    2. Create virtual machines using formal scripts on the cloud.
    3. Check all the machines do not need to open the port.
    4. Check the database is not set a password or use the default password, especially MongoDB and Redis.
    5. Log in to your machine using SSH instead of using a password and log in via SSH key authentication.
    6. Update the system in time to prevent 0day loopholes such as Heartbleed, Shellshock, etc.
    7. Modify the server configuration, HTTPS uses TLS1.2, disable other modes. (It's worth it)
    8. Do not open the DEBUG mode online, some frameworks, DEBUG mode will open a lot of authority and backdoors, or expose some sensitive data to the wrong stack information.
    9. Prepare for bad guys and DDOS attacks using host services that provide DDOS cleaning
    10. Monitor your system and log it into the log (eg using New Relic or something else).
    11. If it is 2B business, insist on compliance needs. If you use AWS S3, consider using data encryption features.If you use AWS EC2, consider using the disk encryption feature (now the system boot disk can be encrypted).


    About people :


    1. Open a mailing list (for example: security@coolcorp.io) and collect pages for security researchers to submit a bug.
    2. Depending on your business, limit access to the user database.
    3. Be polite about people who report bugs and vulnerabilities.
    4. Review your code for peers who have a safe coding concept (More eyes).
    5. Black or data leak, check the data before the visit log, notify the user to change the password. You may need an outside agency to help audit
    6. Use Netflix Scumblr to stay informed about your organization's (company's) discussion of information on social networks or search engines such as hacking, exploits, etc.


    Original Post -> https://github.com/FallibleInc/security-guide-for-developers/blob/master/security-checklist-zh.md

    Comments

    1. Thanks for taking the time to discuss this, I feel strongly about it and love learning more on this topic. application security provider

      ReplyDelete

    Post a Comment

    Popular posts from this blog

    Source Code Review

    Cyber Security and DFIR Interview Questions