SoftwareSecurity2013

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 Erik Poll <erikpoll@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.

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. Every group of 4/5 students picks

• a case study (a web application) and
• a topic (a set of security requirements to investigate for this case study

explained in mode detail below

Forming groups

See list of groups and people looking for a group

Case studies

Two case studies for this you can choose from are

• FluxBB - a php bulletin board with some 'modifications' (ie. extensions of it). A sample FluxBB v1.4.8 website is available at: [1]
• MediaWiki - a php wiki with the AWC forum extension. A sample MediaWiki website is available at [2]

but people can come with other web apps as case studies. (Only constraints: they have to be open source, because 1) people need to be able to access the code and 2) our academic license for Fortify does not allow commercial use on proprietary software.)

Topics: Verification Requirements

Topics: either a set of security verification requirements (Vn):

• V2: Authentication including V7: Cryptography
• V3: Session Management , V10: Communication Security, and V11: HTTP Security
• V4: Access Control and V9: Data Protection
• V5: Input Validation
• V6: Output Encoding/Escaping (HTML) plus any other interesting output if there's time (email addresses, path names, ...)
• V6: Output Encoding/Escaping (SQL) plus any other interesting output if there's time (email addresses, path names, ...)
• V8: Error Handling and Logging

Verification requirements that we ignore

• V1: Security Architecture Documentation - there is probably not much architecture documented...
• 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

The work

First step: trying out source code analysis tools, in particular the Fortify Static Code Analyzer (SCA), for a level 1B evaluation. Deadline, April 24th. Make sure that you group wiki includes

• one page reporting on the tool’s findings about code, and how these can (or can not) be used for your verification requirements
• one wiki page reflecting on the tools (are tools like this of any use? Could they be - in general or for the security requirements that you are looking at specifically?)

Second step: a level 2B evaluation, to be complete before June 20th. For this, make sure that your group wiki includes

• one page listing the security verification requirement, with your motivated verdict on whether each requirement is met or not. If you are not completely sure whether the security requirements is met or not, or not sure at all, don't hesitate to say so, explaining the source of your uncertainty.
• one page reflecting on the whole OWASP ASVS experience, eg discussing issues such as
  • What difficulties did you encounter, either with the code or the ASVS? Can you think of ways to reduce or avoid these difficulties?
  • Could the ASVS be clearer, more complete, or structured in a better way?
  • Is splitting up the work as we did,with different groups looking at different security requirement, a sensible way to split the work? Or are there more practical ways?
  • What could or should developers do to facilitate a security assessment? Do you think that experiencing security from the perspective of a reviewer rather than a developer has changed the way you would design or implement a web application yourself?
  • Any other interesting, frustating, boring, educational, etc. aspects of the whole experience.

  As usual, best to keep things concise and to the point. Try to say conciselt what you want to say, don't think that simply producing more prose will get you a better grade :-).

On Friday June 21st I'll schedule meetings with the individual groups to discuss your results.

Groups

• Group 1
• Group 2
• Group 3
• Group 4
• Group 5
• Group 6
• Group 8
• Group 9
• Group 10
• Group 11
• Group 12
• Group 42

Documentation generation tools

The tools below automatically generate some documention and API information from source code.

• PHP Documenter
• Doxygen

Information

• The Open Web Application Security Project (OWASP) is a community effort to improve the security of web application. The OWASP website provides a lot of information, though, as in most wikis, the relevant information can be a bit hard to find in the maze of wiki pages. Useful pages at the OWASP site include:
  • The OWASP Application Security Verification Standard Project (ASVS) has produced the 'ASVS;which describes standard procedures to assess the security of a web application. For this project, the detailed verification requirements (V1, V2, etc) are interested as lists of specific issues to look at.
  • The OWASP Code Review Project has produced more detailed info about doing a code review (as part of a security verification). This is resulted in the has produced the Code Review Guide, which is available as HTML . PDF , DOC, and paperback
• (CWE 661) Weaknesses in Software Written in PHP
• Useful PHP info
• Anything else?