Category Archives: Web Dev

Open Run Log

Since getting some extra time over winter break I was able to dig up a project from earlier this year. I’ve posted a few previews of my progress on Twitter over the past few days – but today I’m ready to open up the site for others to test and use.

Open Run Log is a website that I built to use as a training log. I’ve built in some auto-generated graphs and have ideas for other things in the future like goal setting and tracking, public profile pages and sharing, custom graphs, or other fun things. It is at a point where I felt comfortable switching to it for tracking my runs and so today I imported my old training log into the site so that I didn’t lose that data. It is only going to improve from here on out and I’m very excited by the possibilities! (Yes, I’m a data nerd when it comes to my running log.)

year

 

So why not use one of the many other run tracking websites? Because I didn’t want to miss the chance to mix my two passions (running and coding). Also I was excited about all the different ways in which I could analyze run data in the future so having control over the code and data was important to me – and I wanted to give that freedom to others as well which is why I made the source code available. I think that projects like WordPress and ThinkUp provide great software and have a great model of making both the software and code available to anyone interested and I wanted to do the same.

If you give it a try, be sure to let me know what you think!

 

Announcing coursegrab: SHIPIT

In recent posts I’ve hinted at a new project and I’m ready to show off the first version:

coursegrab screenshotCoursegrab is a little project that I’ve been wanting to build for a while now. The idea is simple: My university doesn’t provide waitlists for all classes so that students can automatically be enrolled in a class when space opens up which means students are always checking the website for class status.

This service will send a text message when a class you want opens up. No more checking whether you can get into that class you want to take!

Redis

I’d like to build something using only Redis for persistence. Its new scripting interface seems really cool. I have ideas, just need to get out of this busy project/exam filled time… maybe Thanksgiving break will give me enough time.

UMich Students: Stay tuned.

How MCommunity Works

In my last post, I briefly mentioned that I thought MCommunity was sitting on a pretty nice JSON API. Today, I’ll be covering some of the endpoints that I mentioned and what the data looks like when it comes back. I’m writing this not because it was particularly difficult to figure out – anyone with a web browser can do it quickly with the developer tools – but because I enjoyed getting a glimpse into how the service was structured.

When I first looked at it, MCommunity had an endpoint that the Javascript was POSTing to to get details about who was logged in.
Doing a GET to https://mcommunity.umich.edu/mcPeopleService/private/people/getAuthorization/dummy will give a few details about the user who is currently signed in. For instance, when I am signed in, mine looks like:

{
    "authcheck": {
        "errors": "",
        "authStatus": true,
        "displayName": "David Thomas Wilemski Jr",
        "dn": "uid=dtwilems,ou=people,dc=umich,dc=edu",
        "elevatedStatus": false,
        "uniqname": "dtwilems"
    }

}

Note: They’ve since stopped using the “dummy” signifier in place of some sort of numerical ID; My guess is that it was an attempt to change that endpoint per session so it wouldn’t be so easy to call. However, “dummy” still works as does any integer – and most strings too. Maybe it was changed for some other reason, I guess I’ll never know.

As you can see, this is very useful information when exploiting XSS. It tells you exactly which user is currently authenticated. While the XSS vulnerability was still present, I could have written a script to notify me when someone viewed my profile and tell me exactly who was viewing it. Furthermore, because the script would have been executing in the context of the other user, it could have used the next endpoint that I’ll be discussing to ask for all of a user’s personal information that is stored in MCommunity and send that to a malicious attacker. That’s some serious analytics.

The next endpoint gives information for a uniqname based on who the user asking for it is. For instance, the URL:
https://mcommunity.umich.edu/mcPeopleService/private/people/dtwilems
gives info on me! Here is what I see when I view the page:

{
    "person": {
        "distinguishedName": "uid=dtwilems,ou=people,dc=umich,dc=edu",
        "errors": "",
        "aboutMeView": 2,
        "acl": [
            "3#entry#ou=People,dc=umich,dc=edu#drink",
            "3#entry#ou=People,dc=umich,dc=edu#umichAltPhone",
            "3#entry#ou=People,dc=umich,dc=edu#umichAltAddress"
        ],
        "affiliation": [
            "College of Engineering - Faculty and Staff",
            "CoE-IT - Faculty and Staff",
            "Undergraduate Engineering - Student",
            "Alumni"
        ],
        "aliases": [
            "David Thomas Wilemski",
            "David Wilemski Jr",
            "David Wilemski",
            "David T Wilemski",
            "David Thomas Wilemski Jr"
        ],
        "altAddressView": 1,
        "altPhoneView": 1,
        "associatedDomain": "engin.umich.edu",
        "displayName": "David Thomas Wilemski Jr",
        "drink": "Cranberry Juice",
        "email": "dtwilems@umich.edu",
        "emailForwarding": [
            "dtwilems@mail.umich.edu",
            "dtwilems.umich@gmail.com",
            "dtwwtd@gmail.com"
        ],
        "faxPhoneView": 2,
        "ferpa": "N",
        "homeAddressView": 2,
        "homePhoneView": 2,
        "imView": 2,
        "mobilePhone": "------MY CELL NUMBER-------",
        "mobilePhoneView": 2,
        "noticeView": 2,
        "pagerPhoneView": 2,
        "permanentAddress": "-------PLACE WHERE I LIVE--------",
        "spamFilter": "TRUE",
        "title": "Student, Undergraduate Engineering",
        "uniqname": "dtwilems",
        "urlView": 2,
        "vacationView": 2
    }
}

 

However, if I call the API for someone else’s info then it only returns information that they have marked as public. Well, actually, you can mark things as public, or just viewable to logged in users (auth), or private (self). They actually return information structured pretty well, and as we’ll see, I’ve since discovered more API endpoints like these – but first I’d like to talk about the last endpoint that I used while digging around with the XSS exploit.

This is the one that really made things go. POSTing to this with the correct variables and a valid cookie will update a profile:

https://mcommunity.umich.edu/mcPeopleService/private/people/updateContact

This is the one that could have helped to cause the MySpace worm of MCommunity – if I was evil. Instead, I reported it like any upstanding Michigan community member would have. :D

Conclusion

So, like I said, the MCommunity site has a nice API. As a matter of fact, Bryan and I have just discovered some various WADL files that describe additional endpoints. I’ll list the ones we know about out now for some of you curious folk:

  • https://mcommunity.umich.edu/mcPeopleService/
  • https://mcommunity.umich.edu/mcDirectoryMessages/
  • https://mcommunity.umich.edu/mcGroupService/

What would I like to see MCommunity do with its API? Open it up! I mean, we’re a top computer science school for crying out loud! I think that the students and alumni here could do some truly amazing things if this were to be opened up and documented a little better. Actually, this is something I think that the entire University could do better. Initiatives like the Mobile Center are great but the applications that they put out are still purely proprietary. In fact, their APIs page has had basically a “coming soon” message on it for over a year now.

As it is, any student who wants to build a mobile or web application related to the University is usually forced to revert to lame attempts at scraping a web page for information and other gross, hackish things in order to get functionality out of their application. I’ve experienced this first hand with both Umich Dining and MSchedule. We actually found computer readable formats for both of those applications but not without some exploring first. The data feeds aren’t advertised in any way and I think that they need to be. I’ve heard very similar stories over and over from other students who have tried to build some Michigan specific application at a hackathon or for other purposes and, honestly, it gets frustrating.

I will say that it seems that the University is getting better at trying to support development here on campus – we’re just not quite there yet. If anyone who works for the University who can help move this along is reading, just know that you’re moving in the right direction – we just want you to get there faster!

Also, us MSchedule developers would like to be able to register users for classes so as to create a much better user experience. Pipe dreams, we know…

MCommunity XSS

The University of Michigan recently launched a new directory site called MCommunity that is to be used to search for information on people related to the University.

A few days after the site launched my friend Bryan Kendall found a persistent XSS vulnerability in MCommunity within a couple minutes of looking at the site. He reported the problem to the Michigan security team.

…Or how I almost wormed MCommunity

Days passed and I got curious about how MCommunity itself worked as it obviously used a lot of AJAX to load information on pages. So I took a look at what those calls looked like using Chrome’s developer tools. It looks as though MCommunity is sitting on top of a pretty nice JSON API! They included endpoints for gathering info on an account, the current user’s auth info, and various other endpoints including the one for updating a profile.

So what did I do? I wanted to update my own profile via XSS of course – just to see how it worked. I embedded a Javascript snippet in the alt address field that Bryan found was vulnerable that loaded an external script hosted on my server.

Screenshot of the snippet in the form before I submitted it

That external script simply made some AJAX calls to various endpoints with the purpose of updating the user who was viewing my profile’s Alt. Phone number to “I have you now”. This was accomplished by grabbing the user’s authentication information and posting to the proper place; because the Javascript was being executed in the context of a logged in user it posted their existing auth cookie along with the post and acted on behalf of the user but without their permission.

Screenshot of the modified field on my profile after being XSS'd by myself

After testing this to see if it worked with a couple of friends (letting them know what would happen before hand), I stopped loading that script into my profile so as not to actually modify anyone else’s data. I replaced it with a simple alert that said that MCommunity was vulnerable and that concerned users should notify the University.

Had I been malicious, I could have modified others’ profiles so that when they were viewed, they too would attack other people’s profiles. This worm could have spread out of control and caused much grief. There are also any number of other things that an attacker could do with an open XSS bug. This is why testing for these things in development is so important.

Response

I promptly reported the vulnerability as well because I didn’t want others doing this to me! I quickly got a response from the security team saying they had passed it on to the MCommunity team. About a week later, on August 2nd,  I noticed that the vulnerability had been fixed and no longer worked. They must have patched it in one of these releases – despite not mentioning it in those notes.

Overall the response from the University was very good. I do hope that they are on the lookout for further vulnerabilities in the application. It houses so much information on the entire Michigan community that it would be disappointing to see that be abused by a malicious attacker.

WebPastr revisited

Last October I wrote about my first experience with Google App Engine which took the form of a reallllly simple service that I called WebPastr.

It has been something that I built once and sort of forgot about. I’ve used it off and on since building it but no one else has – which is about what I expect. One thing that was unexpected, however, was the fact that shortly after writing that first blog post about it, it got posted to reddit’s /r/AppEngine. As it happens, I only found this out after the fact; and to make matters worse I have no idea exactly how my post was originally found because I had just gone through a web host change and had forgotten to set up analytics again. So to that poster, if you’re reading this – thanks! :)

As you can see, it was by no means a huge amount of traffic (huge in the sense of reddit or Digg front page huge), but it was a ton for my tiny site that only gets maybe a handful of views a month. It was the first time I really thought about the fact that I can produce things that people want to know about though.

So why this post now? Months later, nobody cares about this right? Yeah, well pretty much. Something I planned on doing a while back was releasing the source to this so others could learn from it. I’ve progressed so far since then, but even though it’s really basic, it was valuable to me in understanding the structure of a App Engine/Python web app. So that’s what I’m finally doing today. WebPastr is now up on github; Anyone can see just how simple this little idea of mine was to implement and hopefully it will help others in some small way – and who knows maybe I’ll actually end up doing more with it now that it’s public so that I can be less embarrassed about how simple it really is!

Building a quick and dirty web service on Google app engine: WebPastr

Update (5/26/2011): I’ve now open sourced the code and wrote a little more about WebPastr

Earlier this week I though that it would be nice to post a text snippet to PasteBin via Alfred on my Mac. I looked into how a new pastebin post is posted and was dismayed by the fact that I couldn’t set it up just with Alfred’s wonderful custom search feature.

Last night I decided to build a quick app engine application as an intermediate step between me and PasteBin.

I’ve done a little (unpublished) work with Python on app engine before so I quickly chose that as my language. I knew enough to get me going. I had to write a main page (this still must be done) and the script that would handle my requests and forward them on to PasteBin.

I am happy to say that in under an hour I got it working with a very rough set of features; Namely, posting to PasteBin. I have tested that this works if you setup a custom search inside of both Alfred and Google Chrome. I have posted some screenshots of the settings windows for each app here.

One of the things I keep hearing from both people who work at startups and even presenters from Google is to actually release something, to build and iterate.  Even though I don’t even have a webpage designed for the service yet there are no other features yet, I am releasing this. This is not something I would have done before.

In order to create a new post you send a request to this URL: http://webpastr.appspot.com/post?code={yourtexthere}

Alfred Preferences
Chrome Preferences

What are my plans for the future of WebPastr?

First, I’d like to support other services. Definitely Gist when GitHub finally allows the API to post new Gists.

I’d also like to support PasteBin’s post expiration feature.

Lastly, I plan on designing a homepage for the app that clearly explains how to use it in various applications. I believe I could easily get Firefox working with this and maybe a Bash script as well.

Feel free to use this now, and be on the lookout for new features soon!