Universe.com Stored XSS Vulnerability

  English  

The event software used by GitHub for Git Merge on the 2nd and 3rd of February 2016, is Universe.com.

After registering for the purchase of two tickets, I was redirected to my online Universe.com profile. I thought, heck, why not. Let’s add a bit more info to that empty profile.

The developer (and perhaps pentester) inside of me got triggered for some reason, wondering if the contents of my description field would be stripped correctly of HTML tags by the server and client before being stored and publicly showed on my profile.

The XSS payload inside the description field.

And to my surprise, after sending the description to the server by pressing the Update Profile button, I was greeted by not just any alert message. Apparently the XSS injection also broke the front-end client..

Oops. Oops (2)
   

I immediately sent an email to the Technical Support of Universe.com, minutes after my discovery.

So I started to evaluate (pun intended) the situation while waiting for a response.

One might say, sure okay, this is bad. So far only visitors looking at my profile page are affected. But it’s not that, bad right? Well, think again. A developer with malicious intentions could inject his or her own script. For example, he or she could start stealing visitor’s session cookies. Or redirect to a phishing site. Remember, the attacker has full access to the client, and can act as the client on this page.

Now of course, anyone who has basic javascript knowledge could have stumbled upon this. After discovering this XSS vulnerability, he or she could have started pentesting on more webforms available for the end-user. Who knows what other security flaws are waiting to be exploited, if even a small description field is not sanitized?

I can’t imagine what the consequences would have been if an attacker would have found an XSS vulnerability in perhaps the billing area of Universe.com (we are, after all, dealing with a platform focussed on money and credit cards).

After one month, while not having received a single response from Universe.com, the issue seemingly got fixed. HTML tags are now properly removed from descriptions sent to the server. Although a response would have been nice.

You’re welcome, Universe.com :)

Dec 19 2016 Discovery & Notified Universe.com
Dec 20 2016 “This [issue] has been passed along to our development team”
Feb 2017 Issue got fixed (no follow-up email received)
Apr 09 2017 7 days publishment notice sent
Apr 17 2017 Post published

Adding an ICS iCal file to the iOS Calendar in Swift

  English  

Loading an iCal file over the webcal protocol in iOS, is a fairly straight-forward process if you know the caveats. Since I’ve found almost zero documentation on this, I decided to share my findings with the world.

The following is required for iOS to even want to deal with your iCal file:

  1. The protocol of the URL has to be webcal://
  2. The URL has to end with .ics
  3. The server spewing out the iCal file should send a HTTP 200 OK response
  4. The content-type header should be set to text/calendar and an applicable charset (eg. charset=utf-8)
  5. The content-disposition header should be set to attachment; filename="calendar.ics"

If you’re using NodeJS to present the ics file, I highly recommend the ical-generator package written by Sebastian Pekarek.

In the code snippet below we load the ics file over the webcal protocol after the user presses a button. Opening the url in the background will prompt the user to subscribe to the calendar, once the iCal file has been parsed with success by iOS.

@IBAction func addToCalendar(_ sender: Any) {

    let url = URL(string: "webcal://api.server.com/example.ics")!

    UIApplication.shared.open(url, options: [:], completionHandler: { (success) in
        print("Open webcal: \(success)")
    })

}

Below you can see a few dialog options the user could be presented with.

Bonus: you can set the calendar name with the following lines in an iCal file:

NAME:My Calendar
X-WR-CALNAME:My Calendar

That’s all there is to it, really. Please let me know if you found this to be helpful for your app, any and all feedback is welcome.