creating an open web application security home
February 10th, 2012 by mgoodwin
Sometimes we’re asked for guidance on something and the result seems worth sharing; this one is about useful things to consider when using JSON for information that needs to stay secret.
If you’re using JSON for private data; make sure you’ve fixed the CSRF side of things and everything will be OK. If you want to try to protect yourself in the (hopefully unlikely) event of your CSRF protection mechanisms failing, read on.
February 3rd, 2012 by gdestuynder
However, we also wanted to:
- Enforce privilege separation at the system level
- Render the potential security issues in the web app code, and other services running less relevant
This is implemented via:
- Role based access control (RBAC)
- Enforced by a Mandatory access control framework (MAC)
MAC vs DAC
- With DAC, the users are responsible for setting access permissions,
such as read, write, execute (those are set by the user owning the file).
- With MAC, the system sets and controls the permissions, and users cannot modify permissions, even of files they own.
RBAC is an access control model, which is enforced by MAC. Note that for compatibility reasons, the
Linux DAC model is still in use. However, MAC has always precedence over DAC.
- File system objects, and some other system objects are grouped into different types.
- With RBAC processes (subjects) are grouped into different roles.
- The roles have a detailed list of permissions for each type.
- The list of permissions is called an access matrix (also called access vector).
- The sum of the access matrices is called the RBAC security policy.
Like in a theater, where the same person can be role playing different
characters, the same processes can be started under different roles (and
even transition to other roles if those are set to be compatible).
For the BrowserID project, we have selected RSBAC as the MAC framework, which
implements a module called RC (Role Compatibility) as it’s RBAC model.
- RSBAC allows to retain both flexibility and very detailed access control (no compromise).
- It is a patch to the Linux kernel, which implements hooks and an access decision framework.
- It has several security models implemented (called modules)
- Each model can return GRANTED, NOT_GRANTED or DO_NOT_CARE (=GRANTED) for each access decision.
RSBAC modules we are using in particular:
- RC The RBAC module
- AUTH The authentication module
- Lists which user ids a process is allowed to switch to.
- You cannot login as a user, or switch to a user id, if you did not allow it through AUTH
- CAP The capabilities module, controls Linux’s capabilities.
- For example we disable root capabilities (root is a regular user)
- One policy file per package.
- Complex and require a lot of maintenance. May require repackaging each package.
- More difficult to customize and extend the policy in some cases.
- Policy enabled only for specific system daemons (RHEL SELinux’s does this by default: it’s called the targeted policy).
- Easier management and setup, but if unprotected daemons/processes are compromised, this does not help much.
- Lower security level.
- Global base policy common to all systems
- Runs on default installs for RHEL 6 systems
- “Role per service” instead of “Role per package”
- Extended by a custom policy file, per system type basis
- BrowserID has such a custom policy file
- Separate NodeJS’s daemons, keys, secure cookie storage, etc.
- Different custom policy for the database, web servers, and so on.
- Faster deployment (no repackaging, no separate per package tests).
- Security policy development team does not need to wait on the package team or vice-versa (in our case, RedHat, which release updates and upgrades independently)
- The security engineer/admin only has to verify the policy works as expected on system update (generally the policy only needs update on major version upgrades like RHEL 5 to RHEL 6)
We plan to have a specific NodeJS RSBAC module, enabling us to switch role from within NodeJS depending on the operation performed, to obtain a more detailed separation.
- Critical code sections could run with an elevated role.
- Other parts of the process cannot elevate to this role.
- Note that technically this is a hybrid form of MAC+DAC as the process itself decides when to switch roles, but the policy limits which role, by which process, and so on.
- The elevated role, still has a very detaille policy which does not give access to more than what it needs.
When a regular code section has a bug and the exploitation of the bug gives system access or the ability to run system commands/access the filesystem/access the database, the attacker will be contained in their role and RSBAC will deny access to the types that the elevated role would have access to (for example, cookies and keys).
Therefore, even if the root or an administrative user was compromised,
the attacker would again, be limited by:
- The role’s access matrix
- The capabilities allowed for the process that has been compromised
- Switch to the user IDs AUTH permits for this process.
In short, the detailed access control severely reduces the attack vectors.
January 31st, 2012 by Frederik Braun
On January 25th, with the help of many volunteers, we hosted the first Mozilla Capture The Flag (CTF). The Mozilla CTF will be a recurring security event, although we are not yet prepared to announce when the next iteration will be. CTF participants competed against each other trying to research flaws, exploit vulnerabilities or find hidden messages embedded in different (web) applications.
The CTF consisted of 22 challenges. Most challenges involved little hacking experience to present newcomers a low bar to overcome.
The covered topics included reverse engineering, cryptography, web application hacking, exploitation and trivia.
We had 211 teams participating from all over the world, of which 119 stole at least one flag. Many teams consisted of small groups up to 5 people.
The overall traffic amounted to 11 GiB and our servers handled it quite well
Within 24 hours, every challenge got solved. We had a close fight for the first place with LeetMore ending up on first and Eindbazen on second place, being only 4 points apart by having solved everything. You can see some nice graphs about the standings and how they evolved throughout the CTF. A lot of teams performed well and many did a great job to sum up all the tasks and their solutions.
Besides all the hacking, we also had a fun challenge where people were supposed to dress up in a swim-suit.
Fortunately, no serious security flaws were misused to break other people’s experience and we hope that everybody had a safe ride 😉 Ultimately we would like to thank all the participants for making this event so enjoyable!
January 10th, 2012 by Frederik Braun
We are excited to get this much attention with our CTF. Unfortunately, this means that we will have to close down registration soon.
Registration will be closed on Friday or as soon as we hit the limit of 150 teams (currently 110 teams registered)
Update: Registration is closed
January 7th, 2012 by Frederik Braun
This is an update on the prior Mozilla CTF announcement:
As mentioned earlier, the CTF is on January 25th and will go for 24 hours.
Everybody is invited, also see FAQ
Teams registered via E-Mail beforehand have already been added to our list
January 5th, 2012 by Frederik Braun
- a class for test results based on HTML content
- Check for mixed-content
December 21st, 2011 by yboily
Several members of the Mozilla Security team will participate in an AMA on reddit this morning. You can find it here!
December 19th, 2011 by yboily
Announcing the Mozilla CTF hacking competition
Per the announcement during Frederik Braun’s presentation today, Mozilla will host a CTF event in January, 2012.
The Mozilla CTF will take place on January 25, 2012 (24 hours, PST). (Yes, this is a business day. Sorry)
The competition will be open for 24 hours to allow people from all over the world to participate.
This CTF is mainly aimed at the Mozilla Community and is designed to be accessible to people of all skill levels. There will be two registration phases, with the Community registration opening first. If you are a member of our community and are interested early registration, please reach out to your contacts within in Mozilla, or the CTF organizers (fbraun at mozilla.com, or yboily at mozilla.com)
Other players are still encouraged to join us, but please note that this CTF is mainly aimed at people who are new to Capture The Flags and the skill level has been adjusted accordingly.
Detailed information can be found at https://wiki.mozilla.org/Security/Events/CTF/ and you can watch this blog and follow @mozwebsec on twitter for updates.
December 14th, 2011 by yboily
One of the important projects that Mozilla has been building in 2011 is BrowserID, a user-centric identity protocol and authentication service. Significant work has gone into building out and testing the infrastructure and protocol to make sure that it is a robust, open, and simple to adopt authentication scheme. If you want to learn more about BrowserID, here is a quick 12 minute video that explains what it is, and why we are doing this.
BrowserID continues to evolve as we build support for it across Mozilla properties and encourage adoption from 3rd parties. To date there almost 1000 different websites that rely on BrowserID, but we still have a long way to go to see large scale adoption!
Much of the effort we have put into reviewing the protocol and implementation of BrowserID is discussed in a recent presentation, a recording of which can be found below:
[Slides: html | html(zip) | pdf]
(if the video doesn’t appear, click here!)
In addition to ongoing application and infrastructure security work in the next year, we are aiming for two significant milestones in 2012. First we will engage two third party security reviews of the Browserid.org site, and the cryptography used in BrowserID (including the protocol, the algorithms used, and the libraries we are relying on). Our objective in doing the third party review is to remain as transparent as possible in the development and review of the security aspects of BrowserID. This commitment to transparency includes:
- opening up currently closed security bugs as the issues are resolved
- publishing the results of the 3rd party review once high risk issues are addressed
As we proceed with this effort we will publish additional information on this blog, and we will work to keep the community up to date at each stage of progress.
Second, once we have completed the 3rd party review, resolved the issues identified, and published the results, BrowserID.org will become one of the properties fully covered by the Bug Bounty program (as always, exception bugs reported for none covered sites will be considered for bounty nomination).
December 12th, 2011 by mgoodwin
On Wednesday 14th December, Mark Goodwin from Mozilla’s Infrastructure Security team will be presenting a guest lecture on web and application security at Sheffield Hallam University.
The talk explores how a system is viewed by an attacker and how adopting the attackers’ mindset can be useful in improving the security of what we build.
If you’d like to attend, head to the Adsetts Learning Centre (room 6619) on Sheffield Hallam University’s City Campus in time for a 5pm start.