Brontekst bekijken van SoftwareSecurity2013

{{Workspace
|Short title=Security
|Language=English
}}
[[Categorie:Scholar]][[Categorie:ACCESS Erik Poll]]

[[Image:kerckhoffs.jpg|right]]


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
[http://lab.cs.ru.nl/laquso/Help:Contents here].

Here we collect information and results for the [http://www.cs.ru.nl/~erikpoll/ss/project2 OWASP group project] in the 
[http://www.cs.ru.nl/~erikpoll/ss/ 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 [[SoftwareSecurity2013/groups|list of groups and people looking for a group]]

==Case studies==

Two case studies for this you can choose from are

*[http://fluxbb.org '''FluxBB'''] - a php bulletin board with some 'modifications' (ie. extensions of it). A sample FluxBB v1.4.8 website is available at: [http://nfctool.com/fluxbb/] 
*[http://www.mediawiki.org/wiki/MediaWiki '''MediaWiki'''] - a php wiki with the AWC forum extension.   A sample MediaWiki website is available at [http://auguste.kerckhoffs-institute.org/Main_Page]

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:  [[SoftwareSecurity2013/CodeScanners|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

<ul>
<li> one page reporting on the tool’s findings about code, and how these can (or can not)  be used for your verification requirements 
<li> 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?)
</ul>


<p>


Second step: a level 2B evaluation, to be complete before '''June 20th'''.
For this, make sure that your group wiki includes
<ul>
<li> 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.
<li> one page reflecting on the whole OWASP ASVS experience, eg discussing issues such as
<ul>
<li> What difficulties did you encounter, either with the code or the ASVS? Can you think of ways to reduce or avoid these difficulties?
<li> Could the ASVS be clearer, more complete, or structured in a better way?
<li> 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?
<li> 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?
<li> Any other interesting, frustating, boring, educational, etc. aspects of the whole experience.
</ul>
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 :-).
</ul>

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

==Groups==


*[[SoftwareSecurity2013/Group 1|Group 1]]
*[[SoftwareSecurity2013/Group 2|Group 2]]
*[[SoftwareSecurity2013/Group 3|Group 3]]
*[[SoftwareSecurity2013/Group 4|Group 4]]
*[[SoftwareSecurity2013/Group 5|Group 5]]
*[[SoftwareSecurity2013/Group 6|Group 6]]
*[[SoftwareSecurity2013/Group 8|Group 8]] 
*[[SoftwareSecurity2013/Group 9|Group 9]]
*[[SoftwareSecurity2013/Group 10|Group 10]]
*[[SoftwareSecurity2013/Group 11|Group 11]]
*[[SoftwareSecurity2013/Group 12|Group 12]]
*[[SoftwareSecurity2013/Group 42|Group 42]]

==Documentation generation tools==

The tools below automatically generate some  documention and API information from source code.
*[http://www.phpdoc.org/ PHP Documenter]
*[http://www.stack.nl/~dimitri/doxygen/ Doxygen]

==Information==

* The Open Web Application Security Project (OWASP) is a community effort to improve the security of web application.  The  [http://owasp.org 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 [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project 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 [http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project 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 [http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents  HTML ]. [https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf  PDF ], [http://www.owasp.org/images/8/8e/OWASP_Code_Review_Guide-V1_1.doc  DOC], and [http://www.lulu.com/content/5678680 paperback]
*[http://cwe.mitre.org/data/lists/661.html (CWE 661) Weaknesses in Software Written in PHP]
*[[SoftwareSecurity2012/php|   Useful PHP info]]
*Anything else?