SoftwareSecurity2014

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] Warning: MediaWiki is BIG so something smaller might be nicer.

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: a set of security verification requirements (Vn) as defined in the OWASP ASVS 1.0

• 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

NB there is a beta version of an updated ASVS out and on the OWAPSP website, which reorganises and renumbers some of the verification requirements, but easier if we all still to the old one; you could have a peek at the new one to see if anything interesting changed for the requirements you are looking at.

The work

First step: trying out source code analysis tools, in particular the Fortify Static Code Analyzer (SCA), for a level 1B evaluation. Deadline, May 5. 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 6. 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. Don't think that simply producing more prose will get you a better grade :-).

Groups

• Group 1 Erik Schneider, Chris Mavrakis, Romanos Dodopoulos, Alexandru Geana, Wouter de Groot (TU/e): V3, V10, V11 for FluxBB
• Group 2 Markus Klinik, Koen van Ingen, Joost Rijneveld, Judith van Stegeren (RU): V6 for OwnCloud
• Group 3 Matthijs Hendriks, Mathijs Vos, Nicky van Rijsbergen, Thomas Nägele (RU): V5 for FluxBB
• Group 4 Andy Cui, Aniket Chaudari, Elif Ozgen, Fitria Nur Andini (TUe): V5 for Mibew
• Group 5 Danny Hendrix, Evertson Croes, Harm Berntsen (RU): V5 for SMF (Simple Machines Forum)
• Group 6 Evgenios Karampatzakis, Dominik Lang, Matthias Matousek, Jelte Orij (UT): : V4/V9 for Roundcube 1.0.0
• Group 7 Alvin Cai, Sebastian Verschoor, Max Dujisens, Junior Kalawiz (TUe): V5 for Typo3
• Group 8 Inés Carvajal Gallardo, Max Kerkers, Dirk Maan, Herman Slatman, Iwan Timmer (UT): V5 for Wordpress 3.8.1
• Group 9 Roeland Krak, Joep Peeters, Kim Beunder, Joey de Vries, Stijn van Winsen (UT): V2: Authentication and V7:Cryptography for phpBB
• Group 10 Saurabh Kulkarni, Ben Brücker, Tom Tervoort, Niels Kamp: V?? for Piwigo 2.6.2.
• Group 11 Kevin Valk, Marta Azevedo, Mark Dobrinic, Tomas Novickis (TU/TUE): V4 and V9 for Wordpress
• Group 12 Jorrit de Boer, Safet Acifovic, Raoul Estourgie and Djimmer Smits: V5 for Joomla 3.1.0
• Group 13 Ramon van Sparrentak & Rodin Aarssen (RU): V6 for FluxBB
• Group 14 Amnay Mokhtari, Ali Aalaoui : V?? for ??!

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. NB we use version 1.0, not the new (beta) version 2.0.
  • 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?