Language-based security: course project
In order to pass the course, you need to do a project. A project
proposal, a project presentation, and final project
report need to be delivered. Grades will be based on the report and
presentation. Normally, projects should be done in
groups of two.
Project proposal
A project proposal needs to be submitted
by deadline. The proposal should include
- Title
- Background
- The goal of the project
- Relevance to language-based security
- Overview of the planned work
- Schedule (intermediate goals and time to reach them). Note that
your time frame for project work is from project proposal approval to
the project deadline: work on the project should be started in parallel
to work on the labs.
- Target grade: 3, 4, or 5 for Chalmers and G or VG for GU. If the
target grade is 4, 5, or VG, you need to clearly motivate why such a project would
deserve it.
- If for some serious reason you are unable make it to one of the presentation slots
(see the schedule for the slots), please indicate it.
Project proposals should be in ASCII or PDF format and no
longer than one page. Please include your FIRE group number on
the title page.
Project ideas
The intention is that projects are open-ended. Below are some alternatives for
inspirations, but don't feel constrained by these suggestions.
- Security evaluation of the version of Fire (new in 2013)
- A new version of Fire has been released by Arnar - and our course is the
first to use it. A systematic security evaluation is an excellent
project possibility.
- Security evaluation of JavaScript security monitoring (new in 2013)
- A security JavaScript monitor JSFLow is being developed by us at
Chalmers. This project is about security testing the monitor. We
have a web-based interface in the style of the information-flow
challenges (see the exercises) that allows for systematic testing.
- Language-based security for mobile computing
- This may be an investigation of secrecy protection, integrity
guarantees or obfuscation techniques used in mobile phones. You might
want to focus on concrete topics as Android app security or
location privacy in mobile apps.
- Web language security
- Study in depth the security aspects of languages like JavaScript and Flash.
- Constructing secure mashups using Caja
- Identify interesting scenarios for the use of Caja, and implement
such scenarios. Based on the experiments, discuss programming patterns
and discuss possibilities and limitations of Caja for building secure
mashups.
- Implement secure multi-execution in your favorite language
- Secure
multi-execution enforces secure information flow by initiating
multiple runs, one for each security level, and carefully controlling
communication among the different runs. Implement the idea for your
favorite language.
- Case study in Jif
- This may involve implementing a security critical system in Jif,
and investigating security guarantees in the style of this
case study. Can you come up with attacks on Jif?
- Tools for race detection
- Using the Eraser lab as a departure point, experiment with tools
for race detection. For example, Java Race Detector and Healer
appears to be an interesting candidate. Discuss the types of races caught and not caught by
the tool, the security implications and apply the tool to the scenario of the Eraser lab.
- Security protocols
- Implement a demonstration of some of the attacks on authentication
protocols from the lecture on security protocols. Try to make your demonstration both
instructive and fun. You can adapt the style of the course's labs, demonstrating attacks on
a vulernable implementation and securing it.
- Java security
- Conduct an investigation of security in the Java language. One way
for this project is to follow the idea of the previous one and come up with
attacks and overview protection mechanisms.
- Advanced SQL injection attacks and protection
- A rich topic that has direct relevance to language-based
security. If you go for this project, make sure that this goes
well beyond the kind of simple attacks in the WebAppSec lab.
- Advanced cross-site scripting (XSS) attacks and protection
- The plague of today's web, and an area where language-based
security has a lot of potential. Again, if you go for this project,
make sure that this goes beyond the kind of simple attacks in the
WebAppSec lab.
- Language-based obfuscation techniques
- A hot area and one that is hard to get right!
-
Security review
-
Get hold of an open source system (such as php discussion forum or
Java petshop) and scrutinize the code for vulnerabilities discussed in
the course. The analysis should address both general principles of
security design (see the lectures) as well as concrete issues such as
races, random number generation, the use of cryptography, access
control, etc. Hint: pick a fresh target (rather than an
established system), to increase changes of finding interesting vulnerabilities.
- Survey
-
Pick an area in language-based security and prepare a thorough survey.
- Research paper review
- Pick this project only if strongly
interested in research. Reviews have to be demanding - not simply
summarizing the papers, but making critical
judgments. Suggest papers in language-based in the project
proposal (here
is a paper list for inspirations but it is not exhaustive ). Once
approved, for each paper, you need to produce review based on this
template.
Grading policy: 3 papers = 3, 4 papers = 4, 5 papers =
5. Shallow and late reviews will not be counted.
- Your own project
-
As open-ended as you can get. Be careful in making your proposal
concrete - it is easy to aim for a project that is not feasible within
the course's time frame.
Here are examples of presentations from 2006 (please avoid exact repetition!):
Project presentation
Projects should be presented during one
of the last two lecture slots. Watch out for the presentation schedule on the main
page.
The duration of the presentation is 10 minutes plus 3 minutes reserved
for questions. The opponents are expected to ask at least two questions.
A rough structure of your talk should be as follows:
- Title
Include the names of everyone in the project group.
- The goal of the project
Describe the goal of the project. Include the necessary background.
- What you have done
Give a brief overview and focus on some interesting concrete
parts. Emphasize your own ideas.
- Evaluation
Did you achieve the goal? Describe your results.
Finish by crucial insights (coming out of your project) you want to
share with the others.
Project report
A project report needs to be submitted
by deadline.
The project report should be well-structured. Below is a template that
you might want to use. Note that different projects might benefit from
different structures.
- Title
- Background
- Goal
- Description of work
If this is an implementation project,
describe the conceptual part and code documentation part
separately. In the code documentation part, describe the structure of
the code and what each of the submitted files contains. If
appropriate, include the results of test runs. Also, include
instructions on how your programs should be tested.
- Results
- Appendix: Detail the contribution of each person in the group.
Be careful to fulfill the
requirements of what needs to be provided (see the
descriptions above). Name the documentation file report.txt or
report.pdf (the report should be either in ASCII or PDF), make sure
to include your FIRE group number on the title page, and submit
it together with the rest of the files necessary for grading the
project (and testing your programs).
There is no requirement on the number of pages. Typically, projects
that are heavy on implementation use less pages for reports than
projects heavy on conceptual studies. On average, reports tend to be
around 20 pages long, but the deviation depends on the subject.
Project report draft
Report drafts need to be supplied to the "opponents" by the
respective deadline. The draft does not have to be polished, it should
be intelligible and sufficiently clear for the opponents to assess the
main contributions.