5218COMP - Common Vulnerability Issues Quiz

Course Information

• Course title: 5218COMP – Secure Software Development
• Lecturers: Dr. Max Hashem Eiza ([email protected], Room BS/607A) and Dr. Nathan Shone ([email protected], Room BS/649)

Common Vulnerability Issues

• Approximately 60% of vulnerabilities are due to poor input validation.

Session Overview & Outcomes

• Session topics: Input validation, Authentication, Authorisation
• Learning outcomes: Understand and explain common vulnerabilities, and understand authentication and authorisation concepts.

Terminology Recap

• Threat: What needs protecting? What are you worried about?
• Vulnerability: How might threats become real? Where are the weaknesses in the system?
• Attack: How might someone break the security? Attacks exploit vulnerabilities to realise threats.
• Attack Vector: A path/route/method that exploits weak spots to gain unauthorised access to a computer system. A large part of exploits involve the human element since humans are often the weakest part of the system.

Vulnerabilities

• A weakness that allows an attack
  • Design weakness: A flaw in the design causes an attack not anticipated, e.g., TCP/SYN flood, Heartbleed, SSL RAM dumping
  • Implementation failure: Incorrectly following the design—e.g., incorrect use of Bluetooth, coding errors like SQL injection.
  • Change in requirements or environment: Original assumptions about design or development are no longer valid, e.g., encryption becoming weak, repurposing software without redesigning for the new setup (credit card use online).
  • End-user misuse: Users make incorrect assumptions about the technology, e.g., weak passwords, using sites with inadequate security (SSL certificates), sending executables by email.

Input Validation

• Critical but often overlooked, responsible for about 60% vulnerabilities

• Involves checking the validity of input data.

• Checks should consider:

  • Data type, length, range, and acceptance of null values
  • Checking for possible malicious code injection; e.g., SQL injection.

• Validation should be applied at points where data can enter or exit the software (e.g., URLs, user-supplied files, configuration files, 3rd party data, data loaded from file systems, data loaded from databases).

• Example input validation error: An issue occurs processing a JSP page at line 18 of /index.jsp; a form input causing an IllegalStateException due to mycustomer bean not being available in the request attribute.

• Three validation steps:

  • Constrain: allow known good data. Checks for length, type, and range constraints.
  • Reject: Reject known bad data. Filters for keywords, commands, etc. that may be used to exploit the system.
  • Sanitise: Make potentially malicious data safe. Strips out null characters or spaces.

Authentication and Authorisation

• Authentication: Identifying who you are

• Authorisation: Identifying what you can do.

• These processes should be kept separate in applications.

  • Consider CIA triad (confidentiality, integrity, availability)

• Custom implementations are often incorrectly done, such as in web apps (Guest access), and potential problems arise in logout, password management, or account updates.

  • Password leaks do occur in apps (not just related to sensitive data). This is a common developer error.

  • Password Storage:

    • Never directly store passwords
    • Hash passwords (use SHA-1, SHA256, or SHA512)
    • Use salted hashes for optimal security
    • Consider using a pepper for even more security
    • Consider using hash iterations

  • Password Resets:

    • Password resets are necessary but should be done securely
    • Do not send passwords in reset emails (violates security principle)
    • Request additional information for the user
    • Utilize a unique, temporary token in the confirmation email
    • Implement expiration rules to ensure that the unique token expires swiftly.
    • Prevent automatic log-ins after a successful reset; enforce re-authentication.
    • Session should be made to automatically expire when the session is not actively used or when the browser window is closed to avoid hijacking.

• Session Management:

  • Sessions are used to keep track of users as they navigate through an application. Sessions persist user data between different requests while in scope.
  • Sessions should automatically expire to maintain security
  • Ensure the session is killed when the user logs out.
  • Session IDs must be cryptographically secure (generate random and confidential IDs) and should not be directly sent to URL.

• Authorisation:

  • Limit app resources/actions to authorized users
  • Well-implemented authorisation is difficult
  • Defined roles and privileges crucial
  • Common attacker techniques: bypassing authentication, path traversal attacks, escalating privileges
  • Perform authorisation checks on the server side; do not trust client-side checks alone; and avoid including hard-coded authorisation management information.

• Common Themes:

  • Security is not straightforward (it requires planning and care)
  • Applications must be created securely from the start; relying on existing code requires careful consideration and planning.
  • Think holistically about application security before implementation.

Summary

• Input validation, authentication, and authorisation are crucial for secure software development. Avoiding common vulnerabilities, understanding user authentication and authorisation is imperative.