When a code review is requested by emailing securitysupport@illinois.edu, the Cybersecurity Team will typically start by discussing these questions with Lead and Senior Software Developers who contributed to the code.

These questions are inspired by the Open Web Application Security Project (OWASP) Top Ten Web Application Security Risks. The top ten risks are recalculated every few years based on combined data on actual vulnerabilities. The project is broadly accepted as an authority on cybersecurity risks in custom code.

• Are the authentication and authorization mechanisms properly applied to every resource?
• How is this maintained as the code changes over time?
• Can an outside actor trick a user into triggering a sensitive action in the application?
• Are sensitive actions in the application reversible?
• Are sensitive actions in the application logged?

• Is any data transmitted in clear text?
• Are any old or weak cryptographic algorithms used either by default or in older code?
• Key Management
  • Are default cryptographic keys in use?
  • Are weak cryptographic keys generated or re-used?
  • Is proper key management or rotation missing?
• Is encryption not enforced, e.g. are any user agent (browser) security directives or headers missing?
• Does the user agent (client app) not verify if the received server certificate is valid?
• Does the application store passwords, credit card numbers, social security numbers, grades or other sensitive information?
  • If so, is appropriate encryption being used?
  • If so, is the data storage environment secured to campus IT standards for sensitive information?
• Was any encryption custom developed for this application?

• Is parametrization used for database access?
• Is user data sanitized before being passed to the database?
• Does the application enforce reasonable length limits on all user input?
• What database connectors does the application use?
• Do all database connectors in use support parametrization?
• Do the developers know how to apply parametrization properly?
• Is the database connection code managed by an Object-Relation Model (ORM) or a query framework? If so, does the ORM or query framework automatically enforce parametrization?

• What are your sources of user input to the application?
• Are validation rules enforced for every input?
• How are user inputs sanitized before displaying them back to other users?

• Note: Insecure design focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures.
• Have you documented your software development life cycle?
• Have you established, and are you using, a library of secure design patterns or paved-road ready to use components?
• Threat Models
  • Are threat models documented for critical authentication, access control, business logic, and key flows?
  • A threat model typically contains:
    • Assessment of Scope (Often the topic of the current sprint)
    • What can go wrong?
    • Risk management strategy
    • Assessment (How satisfied is the team with this threat model?)
• Are security controls described by user stories?
• Have you written unit and integration tests to validate that critical flows are resistant to the threat model?
• Have you compiled use-cases and misuse-cases for each tier of your application?
• Have you limited resource consumption by user or service?

• Where is the application hosted, and who maintains the server?
• Is Prisma configured for your environment?
• Are the server administrators aware of cybersecurity best practices for the systems they manage?

• Does the application use XML?
• If the application uses XML:
  • Have the XML libraries in use been checked for known vulnerabilities against a vulnerability database such as the National Vulnerability Database?
  • Does the application use a SOAP XML version prior to 1.2?

• How are versions of external components tracked?
• What processes are in place to update external components as part of the software life cycle?
• If using GitHub, has your team configured Dependabot security alerts
• Are you scanning your environment with Qualys?

• What does your application use for authentication?
• What does your application use for authorization?
• After how long does each user session expire?

• Are digital signatures or similar mechanisms used to verify the software or data is from the expected source and has not been altered?
• Are your libraries and dependencies, such as npm or Maven, consuming trusted repositories?
• Are you hosting an internal repository?
• Is your team's process for vetting new software dependencies documented?
• Does your development pipeline include an automated step to verify the components do not contain known vulnerabilities?
• Is there an established and consistent review process for coding and configuration changes?
• How is your CI/CD pipeline protected?

• Is user session information serialized and shared between the server and client?
• Are serialized data objects accepted from untrusted sources?
• How are deserialized objects verified before being trusted?
• What integrity checks prevent tampering or replay of serialized data?

• Are all security events logged?
• How long are logs containing security events retained?
• How are sensitive transactions audited?
• What automated alerts exist that could indicate suspicious activity?
• Does the team have a documented incident response plan?

Security events include:

• Authentication and authorization events
• Login attempt
• Privilege escalation
• Permissions modifications
• Attempts (success or failed) to view, modify or delete sensitive information
• Attempts (success or failed) to view, modify or delete profile information which could lead to a security compromise (harvesting or changing an email address is a first step in many attack scenarios)
• For more information see Cybersecurity, Logging Practices for Application Developers

From Network layer

• To reduce the impact of SSRF, is remote resource access functionality segmented into separate networks?
• What firewall policies or network access control rules block unexpected network traffic?
• Who reviews firewall rules for existing applications, and what reminders exist to ensure the review happens and any required changes are applied?
• Are all accepted and blocked network flows on firewalls logged (see A09:2021-Security Logging and Monitoring Failures)?

From Application layer

• Is your application built on a web framework with a dedicated URL routing component?

• Is raw unmodified output from any code library or subsystem sent directly to clients?

• Are HTTP redirections disabled?

• Are you aware of the URL consistency to avoid attacks such as DNS rebinding and “time of check, time of use” (TOCTOU) race conditions?

• What percentage of your web application's authentication, authorization and URL routing is custom code (vs handled by a dedicated framework or library)?

• How are your web applications and services isolated from each-other?

  • How sensitive is the functionality and data of those services?
  • Are audiences with incompatible needs using shared components? (Students, Faculty, IT Professionals)
  • Are any services running next to each-other causing unacceptable risks to each-other?

• Who can login to your web facing systems without going through the central campus authentication solution (Shibboleth/Azure Active Directory)?

  • Are those users required to use a Virtual Private Network and Multi-factor Authentication?