Security/Automation/Winter Of Security 2016
- 1 Winter Of Security 2016
- 1.1 Selection process
- 1.2 Timeline
- 1.3 Projects
- 1.3.1 MIG: A web interface for Mozilla Investigator
- 1.3.2 ZAP: Field Enumeration
- 1.3.3 ZAP: Form Handling
- 1.3.4 ZAP: Automated authentication detection and configuration
- 1.3.5 Plug'n'hack / ringleader: Support for e10s (and more)
- 1.3.6 NSS: Demos
- 1.3.7 NSS: Server integration
- 1.3.8 NSS: Blake2 Implementation
- 1.3.9 NSS: Formal Verification
- 1.3.10 NSS: TLS Interop
- 1.3.11 ssh_scan: Improving Scalability and Feature Set
- 1.3.12 Security Testing Workflow and Toolchain for Python Websites and Services
- 1.4 FAQ
- 1.4.1 What is meant by "Presentation of the University program" in the application form?
- 1.4.2 Can students apply to multiple projects?
- 1.4.3 What criteria will you use to select the candidates?
- 1.4.4 Are multiple universities allowed to collaborate and have a single team?
- 1.4.5 Can I still work on Mozilla projects if I am not selected for MWoS?
- 1.5 Project pages
- 1.6 Media
Winter Of Security 2016
The Winter of Security (MWOS) is a program organized by Mozilla's Security teams to involve students with Security projects. Students who have to perform a semester project as part of their university curriculum can apply to one of the MWOS project. Projects are guided by a Mozilla Adviser, and a University Professor. Students are graded by their University, based on success criteria identified at the beginning of the project. Mozilla Advisers allocate up to 2 hours each week to their students, typically on video-conference, to discuss progress and roadblocks.
Projects are focused on building security tools, and students are expected to write code which must be released as Open Source. Universities are free to specify their own requirements to projects, such as written reports. Mozilla does not influence the way grades are allocated, but advisers will provide any information professors need in order to grade their students.
Note on language: English is required for code comments and documentation, but not for interactions between students and advisers. Advisers who speak the same language as their students are encouraged to interact in that language.
Contact us on irc.mozilla.org in the #security channel if you have questions.
Projects are assigned to groups of students. Groups are defined by the universities, and can be of any size between 1 and 4 students. The selection process is open to all students in undergraduate/license and graduate/master programs. A group applies to up to 3 projects by submitting an application that contains:
- the names of the projects the team is applying to
- team introduction and motivation (max 1000 characters)
- presentation of the university program (max 500 characters)
- short description of each team member (skills, interest, ...) (max 500 character for each team member)
- links to relevant resources (university website, resumes, ...)
We will be opening the program for applications on July 29th, closing the application process on September 15th, and announcing results on September 30th.
The students and their professor can decide on the timeline, and make sure that it fits well with other classes. Ideally, projects should not take more than 6 months from start to finish. Mozilla advisors will be available weekly on video (Vidyo, Google Hangout or Skype) to discuss progress and roadblocks, and provide help. Professors can set intermediary deadlines if needed, and have complete control over the grading of their students.
Important Note: Students should apply to one or more project they are interested in. Mentors will pick one team per project. Some projects may not be selected if the mentors consider applicants don't have the necessary skills, or if priority is given to other projects.
MIG: A web interface for Mozilla Investigator
ZAP: Field Enumeration
- Mentors: Simon Bennetts
This would allow a user to iterate though a set of (user defined) characters in order to identify the ones that are filtered out and/or escaped. The user should be able to define the character sets to test and will probably need to configure the success and failure conditions, as well as valid values for other fields in the form.
ZAP: Form Handling
- Mentors: Simon Bennetts
The ZAP traditional and Ajax spiders explore an application by putting basic default values in all forms. These may often not be valid values, for example using "ZAP" when an email address is required. The enhancement would allow the user to define default values based on pattern matching against the field names and/or ids. It would also be very useful if it could show the user all forms and their associated fields for an application, and then allow the user to update the default values.
ZAP: Automated authentication detection and configuration
- Mentors: Simon Bennetts
ZAP has extensive support for supporting application authentication, but configuring this is a manual process which can be tricky to get right. The enhancement would allow ZAP to detect as many forms of authentication as possible and automatically configure them using the existing ZAP functionality.
Plug'n'hack / ringleader: Support for e10s (and more)
Plug'n'hack is a mechanism for configuring a browser profile to work with security tools. Ringleader is a firefox addon implementation of Plug'n'hack that makes it easy to configure Firefox. Since Ringleader was written, there have been major changes to Firefox (most notably, e10s) that prevent the addon from working. We'd like to fix this.
Using the NSS library in your own project isn't the easiest job to do. In this project a suite of NSS demos should be compiled (ideally web executable using something like Runnable) as reference for developers that want to use the library.
NSS: Server integration
The TLS stack in NSS provides basic support for TLS servers such as . With this code being rarely used and tested it contains significant shortcomings. This project should identify those problems, fix them, and provide integration for all major HTTP server.
- An Apache module for NSS exists but lacks important features such as HTTP/2 support.
- NGINX lacks TLS module support entirely. We recently started a push to make it agnostic to the used TLS library. This works has to be continued and requires a new module for NSS.
This project is ideal for a self-motivated group that prefers an open project definition with lots of freedom to shape directions and outcome of it.
NSS: Formal Verification
This project should formally verify implementations (or parts of) of e.g. ciphers, the TLS protocol, libmpi, libec in the NSS library.
NSS: TLS Interop
ssh_scan: Improving Scalability and Feature Set
- Mentors: Jonathan Claudius, pwnbus
This project would work on improving the scalability and feature set of ssh_scan, a tool for scanning for ssh policy and compliance (mainly attributes found here https://github.com/claudijd/ssh_scan/blob/master/examples/192.168.1.1.json). This tool is currently open-sourced as more of a prototype tool here (https://github.com/claudijd/ssh_scan). Current feature gaps include the ability to detect the types of authentication (password/key-based/auth), nmap-style targeting and scanning, and IPv6 support. Lastly, it might be useful to have some server-side infrastructure components/API developed for this service with a cool front end to assist with scanning/compliance automation. These are the sorts of things this project team would attempt to solve and deliver during the project window.
Security Testing Workflow and Toolchain for Python Websites and Services
- Mentors: Adam Muntner
Manual security reviews are time consuming, expensive, and important for the most critical websites and services. By documenting testing goals, trying to best approximate them, and measuring, we can create an efficient, reusable workflow with known properties and a plan to improve it in the future, a Maturity Model approach. The goal of this project is to use Maturity Model approach to create a reusable workflow and toolkit for manual "grey-box" security review of Python websites and services. We will create a maturity model that describes the target capabilities of an ideal reusable "grey box" workflow documentation and toolkit, test available tools, document what works and what's missing according to the Maturity Model, create a test environment that can be dropped in to an existing test environment such as a Docker and used with minimal configuration,and create a roadmap for future work. We will script integration of existing tools and methods to create a reusable test harness that reports testing coverage and supports remote debugging, automate setup to use an IDE to remote debug an application while testing it with Zap proxy, identify the best ways to test for Python-specific issues, make the IDE as tester-friendly as possible, use Python AST visualization to visualize security decisions in code, and making the toolkit as quick to deploy and use as possible, etc. We'll use the toolkit to evaluate complex real-world services like Mozilla Addons. Some preparatory work has already begun for this project, the MWOS goal is to move it to a point where it is a usable, ongoing project.
What is meant by "Presentation of the University program" in the application form?
We would like to see what kind of degree you are currently pursuing (e.g. Bachelor of Science in Computer Science or Master of Science in IT Security, ..), as well as a description of the university itself. This is another data point that gives us more information about the applicants' chances to successfully complete a project.
Can students apply to multiple projects?
Yes. Students can apply to one or more projects. Students cannot apply twice for the same project, even if their team compositions varies.
What criteria will you use to select the candidates?
The skills and passion of the team members are key points. The size of the team may play in the favor of applicants, but is not a requirement. A single candidate who can show a portfolio of successful projects will have the same chances as larger teams. Commitment from the University is a strong requirement. Students need to demonstrate that their professors support them, and will give them time to work on the projects. The ideal situation is for a team to pick a MWoS project as their final thesis, and work on the project for a full semester. Not all students will be able to do so, and we will evaluate all applications with the same level of scrutiny.
Are multiple universities allowed to collaborate and have a single team?
Yes. We will ask that students mentored by multiple professors get approval from all of their professors.
Can I still work on Mozilla projects if I am not selected for MWoS?
Yes! We continuously have projects that are available for students to grab! Take a look at the Mentorship program, and reach out to us in the #security IRC channel if you are interested.
All media files are available under license MPLv2 and can be reused freely.