• Compete
  • Learn
  • Community

    gAudit application hardening








    The challenge is finished.
    Show Deadlines icon-arrow-up

    Challenge Overview

    Secure, Quality code is key to this challenge

    In��descending��order of imporance:

    1. Require the use of HTTPS!

    2. Cookies should use secure AND httpOnly flags

    3. Use OAuth2 (which may require using the latest SDK, see below) to access Google APIs

    4. Allow Client Key/Secret be specified at runtime (not stored in config files as it is currently), but of course ensure that a non-admin user can not break app by supplying bad values

    5. Store client key/secret, as well as negotiated OAuth tokens, in a persisted datastore encrypted using an industry standard crypto library that is whitelisted for GAE (https://developers.google.com/appengine/docs/java/jrewhitelist)

    6. The cryptographic keys used above should be stored in a secure directory that is never web accessible

    7. Ensure that a user has super-admin access to the given domain before allowing PGP key update, or user authorization

    8. Ensure that you can de-authroize someone (TF reported that didn't seem to work in current app)

    9. Ensure that a non-admin user attempting to access the app matches completely (case insensitive, but without the partial match issues) with a user granted access by the admin (See vulnerability #3 in Williams's document)

    10. Ensure access control is applied for all necessary HTTP requests, not just for JSP display

    11. Implement correct auto-logout behavior when session expires (configurable time period)

    12. Do not use volatile storage for data (app should function correctly after a redeploy)

    13. Refactor to use latest and supported Google SDK/API (see William's suggestions)

    14. Inspect current codebase for the hard-to-reproduce vulnerability where a 500 error results in 'free admin access for all' (see��tgkokk_vulnerability.txt)

    15. Implement anti CSRF measures for user-facing forms (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) )

    16. Implement XSS prevention through input validation and output filtering (https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet )

    17. Prevent sensitive data from being cached in browser

    18. Prevent DoS attacks via cron service (see vulnerability 8 in attached doc)

    19. Proper logging using GAE log features

    20. Use GAE best-practice for packaging the application, removing unnecessary libs

    21. Remove hard-coding of domain value (currently ProcessorServlet.java line 151)


    Bonus features ($200 per bonus feature on winning submission):

    1. Better handling of "API��quota exceeded" response (future challenge to handle this even better, but for now at least give a meaningful message)
    2. Base64 encode the PGP key on the fly instead of requiring the user to do it.

    Reliability Rating and Bonus

    For challenges that have a reliability bonus, the bonus depends on the reliability rating at the moment of registration for that project. A participant with no previous projects is considered to have no reliability rating, and therefore gets no bonus. Reliability bonus does not apply to Digital Run winnings. Since reliability rating is based on the past 15 projects, it can only have 15 discrete values.
    Read more.


    Final Review:

    Community Review Board



    User Sign-Off



    Review Scorecard