SoftwareSecurity2012

Uit Werkplaats
Ga naar: navigatie, zoeken
Kerckhoffs.jpg

The FluxBB v1.4.8 forum is online and available at: [http://nfctool.com/fluxbb/]


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 web-applications, namely

  • FluxBB - a bulletin board, and some of the 'modifications' (ie. extensions of it)

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 Roel <r.verdult@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.
After this, you can get on with doing the application verification, which should result in the end result described below.

Groups

Groups:

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

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

or a fluxBB modification (ie. extension), and then covering all relevant security verification requirements for that:

  • Modification: Captcha Registration (version: 1.2.0)
  • [Taken] Modification: Private Messaging (Private messages v3.0.1 was suggested but we (group 4) already started analyzing the highly similar New Private Messaging System 1.5.5 module)
  • [Taken] Modification: support for BBCode (version 1.0.0)
  • Modification: FancyBox (v.1.2.1)
  • Modification: View subjects only (v1.2)

Smaller sets of verification requirements, best combined with others above (or for a small group):

  • [Taken]V9: Data Protection - smaller task; maybe this only concerns (caching of) passwords?
  • V10: Communication Security - only SSL/TLS issues
  • [Taken]V11: HTTP Security - smaller task; may be combined with V3

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

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. ..." )
  • the outcome of your work as it progresses

on your group wiki page. Make sure the log is on a separate wiki page. Maybe you also want to maintain a TO DO list, and record useful about 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.

Final Deliverable

In the end, the results should be presented via one wiki page (Deadline June 21):

  • Organise the results per verification requirement, as they are listed in the 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').

Code analysis tools

First step of the project is trying out some source code analysers for PHP

Documentation generation tools

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

Information

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