Workspace bewerken: SoftwareSecurity2012

Vrije tekst:

[[categorie:work spaces]] [[Categorie:ACCESS Erik Poll]] [[Image:kerckhoffs.jpg|right]] The FluxBB v1.4.8 forum is online and available at: ['''http://nfctool.com/fluxbb/'''] 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 web-applications, namely *[http://fluxbb.org 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 [http://lab.cs.ru.nl/laquso/Help:Contents here]. First step: [[SoftwareSecurity2012/CodeScanners|trying out source code analysis tools]] - Deadline April 22. <br> After this, you can get on with doing the application verification, which should result in the [[SoftwareSecurity2012#Final_Deliverable| end result]] described below. <p> ==Groups== Groups: *[[SoftwareSecurity2012/Group 1|Group 1 (TU/e) V3: Session Management]] - following Privacy Seminar: No, but (two of us) we have to leave at 14:00h in order to make it to our (obligated) course in Eindhoven. *[[SoftwareSecurity2012/Group 2|Group 2 (RU): Modification: support for BBcode ]] - following Privacy Seminar: Yes *[[SoftwareSecurity2012/Group 3|Group 3 (TU/e) V6: (HTML) ]] - following Privacy Seminar: Yes *[[SoftwareSecurity2012/Group 4|Group 4 (RU) M2: Private Messaging]] - following Privacy Seminar: No *[[SoftwareSecurity2012/Group 5|Group 5 (UT) V2,V7: Authentication,Cryptography]] - following Privacy Seminar: Yes *[[SoftwareSecurity2012/Group 6|Group 6 (RU + TU/e) V6: Output Encoding/Escaping (SQL)]] - following Privacy Seminar: Yes *[[SoftwareSecurity2012/Group 7|Group 7 (UT) V4: Access Control]] - following Privacy Seminar: No *[[SoftwareSecurity2012/Group 8|Group 8 (RU + TU/e) V5: Input Validation]] - following Privacy Seminar: No *[[SoftwareSecurity2012/Group 9|Group 9 (RU) V8: Error Handling and Logging]] - following Privacy Seminar: Yes *[[SoftwareSecurity2012/Group 10|Group 10 (UT) V9, V11: Data Protection, HTTP Security]] - following Privacy Seminar: No, but we have obligations in Twente in the afternoon Topics: either a set of security verification requirements (Vn): * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki> '''V2: Authentication''' including '''V7: Cryptography''' * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki> '''V3: Session Management''' * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki> '''V4: Access Control''' * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki> '''V5: Input Validation''' * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki> '''V6: Output Encoding/Escaping (HTML)''' plus any other interesting output if there's time (email addresses, path names, ...) * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki> '''V6: Output Encoding/Escaping (SQL)''' plus any other interesting output if there's time (email addresses, path names, ...) * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki> '''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)''' * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki> '''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)''' * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki> '''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): * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki>'''V9: Data Protection''' - smaller task; maybe this only concerns (caching of) passwords? * '''V10: Communication Security''' - only SSL/TLS issues * <nowiki>[</nowiki>''Taken''<nowiki>]</nowiki>'''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 [http://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_Std_Release.pdf OWASP ASVS]. :For each verification requirement, briefly report your findings. Essentially, this should be done as described in section ''R4 - Verification Results'' of the [http://www.owasp.org/images/4/4e/OWASP_ASVS_2009_Web_App_Std_Release.pdf 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 [[SoftwareSecurity2012/CodeScanners|source code analysers for PHP]] ==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 2009'';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] ** The [http://www.owasp.org/index.php/Category:OWASP_Open_Review_Project#Open_review_process OWASP Open Review Project] sketches a high level process for performing a code review. *[http://cwe.mitre.org/data/lists/661.html (CWE 661) Weaknesses in Software Written in PHP] *[[SoftwareSecurity2012/php| Useful PHP info]] *Anything else?

Samenvatting:

Dit is een kleine bewerking Deze pagina volgen

Annuleren