On 9/8/16 I was invited to give a lecture at the School of Mathematical and Natural Sciences of ASU’s West Campus by the wonderful Dr. Jennifer Hackney Prince. This department is a very interesting and diverse group, so I decided to give a high-level talk about some of the work that we’ve done on securing mobile applications.
I titled this talk “A Computer in Every Pocket: Securing Mobile Applications,” because I believe that mobile applications are fundamentally changing the way that we interact with technology. Furthermore, these devices contain lots of sensitive and personal data, and keeping users safe and this data private is a goal of my research.
I focused on two recent research projects: mobile web applications and the target fragmentation problem in Android. This work is published in the following papers: “A Large-Scale Study of Mobile Web App Security” by Mutchler et al. and “Target Fragmentation in Android Apps” by Mutchler et al. (with a different et al.).
Technical content of the slides are courtesy of the excellent Dr. Patrick Mutchler.
Here is the video recording of the talk:
On Wednesday, June 29th, 2016, I was privileged to give a talk at OWASP Phoenix titled “Everything You’ve Ever Wanted to Know About Black-Box Web Vulnerability Scanners (But Were Afraid to Ask)”.
This was an exciting talk for me, as it was my first ever OWASP meeting. I am a big fan of OWASP, and they have been instrumental to helping shape my knowledge of security. I’m happy to start giving back to the OWASP community.
In this talk I covered parts of the paper Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners, along with the intentionally vulnerable web application WackoPicko, which is contained in the great OWASP Broken Web Applications Project.
I then covered parts of the paper Enemy of the State: A State-Aware Black-Box Web Vulnerability Scanner, which the source code of the state-aware-crawler is available on GitHub.
I also discussed some preliminary work in this area and where I see the field of black-box vulnerability analysis research heading in the future.
There’s also a fantastic Q&A session at the end with great question from the audience.
Here is the video of the talk:
Much of this material is derived from my CSE 591 class, which is a grad class on web security, compressed into a single lecture targeted to undergrads. We did not get to cover client-side XSS vulnerabilities (also called DOM-based XSS) or lots of other cool stuff.
Here is the video of the talk:
Anyway, while playing this game, I discovered a stored XSS vulnerability in DOTS. Here’s how it came about.
XSS in a Mobile Game?
So, while playing the multiplayer mode of DOTS, I noticed that there was a “Share” feature. This feature allows you to share (or brag about) your scores with a friend. What happens is that the app uploads your scores and names to the web server (I haven’t looked into the exact HTTP request that it makes), gets back a unique URL, then allows you to send this URL to someone.
A recent tweet by Steve Keinath aka @keinath about using Agile in the CS classroom led to a discussion between myself and John Miller aka @agileschools. Twitter, while great for starting discussions and connecting people, is not-so-great for conveying nuanced thoughts.
So here I’ll try to summarize my thoughts on Agile in the Computer Science classroom, based on my experiences.
This post is an overview of the paper deDacota: Toward Preventing Server-Side XSS via Automatic Code and Data Separation which was written as a collaboration between the UC Santa Barbara Seclab and Microsoft Research, by yours truly. I’m very excited to present this work at the 2013 ACM Conference on Computer and Communication Security in Berlin. If you’re there, please say hi! (Also, if you have suggestions of places or things to do in Europe, let me know!)
So, what is deDacota?
Previously, we as a research community have looked at XSS vulnerabilities as a problem of lack of sanitization. Those pesky web developers (I am one, so I can say this) just can’t seem to properly sanitized the untrusted input that is output by their application.
You’d think that after all this time (at least a decade, if not more), the XSS problem would be done and solved. Just sanitize those inputs!
This is a true story that recently happened, and I wanted to share/document it here as a reminder to always backup your research data.
Turns out I was so tired after the 24-hour coding blur that was the 2013 iCTF that I didn’t back up the database. Or if I did, I didn’t check it into our SVN repo. Then, to make matters worse, I didn’t make a note to backup the data later.
Here’s a quick Bash function that I whipped up to SSH into a server
and keep the same directory. The use case for me is that I have a
Dropbox shared between my laptop and server. Sometimes I need to run
something (experiment, code, whatever) on the server. It was becoming
ssh and then
cd to the correct directory.
I call this function
sshere (ssh here):
Feel free to use, steal, or adapt to your needs.