adamdoupe

Joined 19 years ago

Karma
216
Submissions
88
Member since
Jun 21
Professor at Arizona State University and DEF CON CTF organizer.

Researching web security, mobile security, network security, hacking competitions, and automated vulnerability analysis.

http://adamdoupe.com

Email: [email protected]

View on Hacker News

Recent submissions

Comment · 4 years ago
If you want to learn offensive security skills, particularly binary analysis, I highly recommend https://pwn.college

It's a hands-on class that takes you through interacting with programs, to reverse engineering and memory corruption, all the way to race conditions and kernel exploitation.

Created by @Zardus and run also as a class at ASU.

Comment · 7 years ago
Comment · 9 years ago
Context here means the context of the output page.

Usually this means the HTML context. Different sanitization is needed depending on _where_ in the HTML document the input is used.

For instance, if the input is used in between HTML tags (let's say $foo is user input in this PHP example):

    ... <body><?php echo $foo ?></body>
Here, the input that you need to transition to JavaScript execution is a < character (among other things): <script>alert(1)</script>.

Therefore, to correctly sanitize this, you would call the PHP `htmlentities` function:

    ... <body><?php echo htmlentities($foo) ?></body>
Now, this XSS vulnerability is fixed.

What if foo is used in a different context?

    ... <body><a href='<?php echo htmlentities($foo) ?>'>...
Here, what we need to transition the HTML parser to executing JavaScript is a ' character, and this can be exploited by the following input (in between the double quotes): "' onclick='alert(1)"

The key problem is that `htmlentities` is not valid sanitization in the context of an HTML attribute value. In this example, you need to use `urlencode`

    ... <body><a href='<?php echo urlencode($foo) ?>'>...
The general idea also applies to CSS, JSON, and JavaScript. SQL is a different vulnerability class (SQL injection).

I highly recommend the following research paper from 2011 that discusses the context-sensitivity of JavaScript in depth: http://www.comp.nus.edu.sg/~prateeks/papers/scriptgard-ccs11...

In my mind, the context-sensitivity of XSS is one of the key reasons why it is so prevalent.

Comment · 10 years ago
In our study we didn't differentiate (from a security perspective, if you are vulnerable because you use a WebView when showing ads, then you are still vulnerable), so I don't have data for that.

It would be interesting data, although determining WebView for ads statically might be tricky.

Comment · 10 years ago
Sure! The short version is that I don't know.

We were looking for instances of insecure WebView usage, so from a security perspective small piece vs. entire app doesn't matter too much (and is difficult to measure, especially when looking at 1.1M apps).

However, some of the other numbers from our analysis can be useful to draw a picture of WebView usage.

We statically looked for uses of WebView, and 85% of the 1.1M apps used a WebView.

Of those 998,286 apps:

- 97% enable JavaScript (which is off by default)

- 36% use the JavaScript Bridge Interface (which is a fairly good indicator of heavy WebView usage)

- 94% implement a shouldOverrideUrlLoading method of the WebView (another good indicator that the developer is using the WebView for something non-trivial)

- 27% implement an onReceivedSslError method of the WebView (indication that the developer is using the WebView for something non-trivial). (Sadly, 29% of the apps that implement onReceivedSslError intentionally IGNORE all SSL errors.)

So I guess the takeaway is that 85% is an upper bound, the real number of WebView-only apps is absolutely lower, however it's clear that WebViews are significantly used in mobile apps.

Comment · 10 years ago
Comment · 11 years ago
Most professor salaries are on 9-month appointments, for the academic year. The three summer months usually come from grants, teaching summer sessions, or consulting.

However, a professor can choose to spend the grant money on student support rather than summer salary (thus forgoing their own salary), which is what I assume the author is referring to.

Comment · 12 years ago
No. Check out the example in the article, an attacker can make your browser submit a form with a POST request using JavaScript.

It's slightly harder to exploit, as the attacker can't just send you a link to facebook.com, but they can send you a link to example.com which has the form and uses JavaScript to submit the form.

Comment · 14 years ago
As I remember, the analysis doesn't handle calls that can't be determined statically.

So the analysis would fail to determine the method and class of a obfuscated string.

Comment · 14 years ago
Comment · 15 years ago
Comment · 15 years ago
I've found that it's not the actual code review that's helpful, but preparing for a code review. It forces you to describe the code clearly, which often makes the code clearer in the process. Plus you try to anticipate the comments your co-workers will give.
Comment · 17 years ago
Hey guys, this is some research that some guys in my lab have been doing.

Pretty cool stuff, they "took over" the Torpig botnet. Lots of interesting stuff, the paper on the link gives a good overview of some of the things they discovered.

Love to hear your thoughts!

Comment · 17 years ago
> if you're looking for motivation, i highly suggest finding some sport that you enjoy doing. go looking for it, i'm sure one exists.

This is exactly what I've done. Rock climbing at a local gym 3 times a week. I also run 3.5 miles 2 times a week but only for the added fitness.

I really enjoy rock climbing; it's an excellent combination of physical fitness and problem solving.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton