Topics Map > Help and Training

Cybersecurity, Code Review Discussion Questions

Cybersecurity Code Review Discussion Questions

About These Questions

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.

Code Security Review OWASP Example Questions

Injection

  • Do your developers use parametrization 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 parameterization?

Broken Auth

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

Sensitive Data Exposure

  • Is any data transmitted in clear text?
  • Are any old or weak cryptographic algorithms used either by default or in older code?
  • Are default crypto keys in use, weak crypto keys generated or re-used, or 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?
  • Was any encryption custom developed for this application?

XML External Entities

  • Does the application use XML?
  • If so, have the XML libraries in use been checked for known vulnerabilities against a vulnerability database such as https://nvd.nist.gov/vuln/search ?
  • Does the application use a SOAP XML version prior to 1.2?

Broken Access Control

  • 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?

Security Misconfiguration

  • Where is the application hosted, and who maintains the server?
  • Are the server admins aware of cybersecurity best practices for the systems they manage?

Cross Site Scripting (XSS)

  • 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?

Insecure Deserialization

  • Is user session information serialized and shared between the server and client?
  • Are serialized data objects accepted from untrusted sources?
  • If so, how are the deserialized objects verified before being trusted?

Using Components with Known Vulnerabilities

  • How are version of external components tracked?
  • What processes are in place to update external components as part of the software lifecycle?

Insufficient Logging & Monitoring

  • Are all security events logged?

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 (i.e. harvesting or changing an email address is a first step in many attack scenarios.)




Keywordssecurity, developer, sdlc, cybersecurity, devops, secdevops   Doc ID106153
OwnerSecurity S.GroupUniversity of Illinois Technology Services
Created2020-09-24 14:28:10Updated2021-01-12 13:29:59
SitesUniversity of Illinois Technology Services
Feedback  0   0