Software Security

Uit Werkplaats
Ga naar: navigatie, zoeken
Kerckhoffs.jpg


Here we collect information and results for the OWASP group project in the Software Security course, in which we do a collaborative security analysis of a web-application, namely an older version of [phpbb].

To get a logon to this wiki, send an email with your full name and your "official" email-address (i.e. a student.ru.nl, student.utwente.nl, or student.tue.nl email adress) to Fabian <f.vandenbroek@cs.ru.nl>.

For non-Dutch speakers: Select "Mijn voorkeuren" above and choose another language. Only the help pages for this wiki will then still be in Dutch, but you can easily find English ones, for instance here.

First step: trying out source code analysis tools - Deadline April 22.

Groups and the Verification Requirements they look at

Groups:

Verification requirements:

  • V1: Security Architecture Documentation - we can try jointly try to collect some information about the architecture and organisation of the code
  • V2: Authentication - looked at by group 9
  • V3: Session Management - looked at by group 6
  • V4: Access Control - looked at by group 7
  • V5: Input Validation - looked at by group 5
  • V6: Output Encoding/Escaping (HTML) - looked at by group 1
  • V6: Output Encoding/Escaping (SQL) - looked at by group 2
  • V6: any other interesting output ? (email addresses, path names, ...)
  • V7: Cryptography - smaller task
  • V8: Error Handling and Logging - looked at by group 3
  • V9: Data Protection - smaller task - only sensitive data might be the email addresses & passwords - looked at by group 4
  • V10: Communication Security - less interesting/small task (mainly TLS issues) looked at by group 4
  • V11: HTTP Security - looked at by (small) group 4
  • V12: Security Configuration - out of scope since this it is specific to a particular install
  • V13: Malicious Code Search - out of scope for a Level 2 evaluation
  • V14: Internal Security - out of scope for a Level 2 evaluation

List of all students in case you're still looking to form a group

Code analysis tools

  • Source code analysis tools .
    There are several source code analysis tools we can experiment with. Below record which tools your group looks at. Also, create/update the wiki-page for that tool to record any problems/successes running them, your impressions about what it can/cannot do etc. The status of some tools is not so clear, so please record it if a tool is effectively dead, to save other the effort to try installing it.
    • Pixy tried out by group ?,3,(7 partial)
      Tool available at here - it works for XSS and SQL injection only, I believe. Tool website is now up!
    • PHP-SAT tried out by group 3,7
      Tool available here. (doesn't have a stable release yet)
    • SWAAT tried out by group 2,3,7,9 (failed)
      Tool available here
    • Yasca tried out by groups 3,5,6,4,9
      Tool available here (also supports use of RATS, Pixy and many other tools though plugins)
    • RATS tried out by groups 3,5,9
      Tool available [1]
    • CodeScan tried out by group 1,5
      Tool available here. CodeScan is commercial, but they offer a free trial download for detecting SQL injection.
    • CodeSecure tried out by group 2,(7 fail)
      Another commercial tool, but they offer free trials here. They are planning to release a new version on May 3rd, so it is currently difficult to obtain free trials.
    • Fortify - we got our license renewed! (5,7)

If you can think of other ways to measure our coverage of possible problems, share info, avoid double work, etc , please add them here.

Info to record/produce

Use your wiki group page to document the process of what you have been doing, and, by the end, to present the results.

To record the process, keep track of

  • a log: Keep a chronological log of your planning and of what you have done. (Eg. "March 22: we met and decided that X would do A and Y would do C. March 22: X actually did A. ..." )
  • a TO DO list
  • Documentation: any info about the architecture of the application (eg. "Authentication is done in packages/files XYZ") or any design decisions (eg. "Apparently, all access control checks are done by calling function f") as you observe them from the code
  • the outcome of your work as it progresses

on your group wiki page Also, record which - if any - warnings from a source code analysis tool you cover and which OWASP Top 10 entries you cover on the communal wiki pages for this.

In the end, the results should be presented via one wiki page (Deadline June 24, prior to the lecture):

  • Organise the results per verification requirement, as they are listed OWASP ASVS.
For each verification requirement, briefly report your findings. Essentially, this should be done as described in section R4 - Verification Results of the OWASP ASVS. For the Risk Rating, don't bother with the OWASP Risk Rating Methodology or Testing Guide, but simply say if you think the risks of any failures are serious or not, with some motivation. Do mention any remedies/improvements that you can think of, which is not mentioned in section R4 - Verification Results.
Be frank in mentioning any limitations of your efforts: things you're not sure of, or things you didn't have time for. If it is useful, you can give a further breakdown, eg of the different types of inputs that are validated, or per directory/file/function (eg, 'all code in XYZ checked for SQL injection problems' - or - 'we didn't have time to investigate Fortify warnings about files XYZ').

Information

Overgenomen van "https://lab.cs.ru.nl/algemeen/index.php?title=Software_Security&oldid=150576"