7
7 Comments

One user could possibly break twitter, facebook, or github - Here's why.

I've been working with Routing and I've found out something that a lot of people probably haven't noticed.

If you go to a site like https://github.com, and navigate to their "about" page https://github.com/about, you can see that the "about" endpoint comes right after the URL.
If you navigate to, let's say my profile in github, you will see that my username comes right after the URL.
https://github.com/Conner1115.
What will happen if a user signs up with the name "about"?
If github doesn't block the user from getting that name, their About page could either override the user, making their profile invisible to all, or make the About page invisible to everyone, displaying the user's profile in place of the original page.

When you do routing in your site, make sure you use something like yourdomain.com/**user**/username instead of making your site vulnerable to people who would try and break your website.

Please don't go breaking github, twitter, facebook, or any other site that uses weak routing for users.

It's good to have a short URL I guess, so if you want, you can use FreeCodeCamp's technique and use something like domain.com/u/username or also, a good way is how repl.it tracks user profile endpoints. They add a "@" before the profile endpoint to ensure that the URL is a user's profile.
domain.com/@username.

Another way (not recommended) is to just validate at the signup form the existing URL endpoints and tell the user that they can't sign up for one of them. I still wouldn't do that because humans make mistakes. If you or I use that way, we will be more prone to err.

Please, next time you make a site, be sure to secure your URL endpoints and watch out for hidden details like this.

Thanks for reading.
Happy Coding!

  1. 10

    I'm not sure this is as big a problem as you think.

    First off, the engineers at these companies you listed are amongst the best in the world, so I don't think this is something that has simply slipped under the radar and no-one has considered it.

    But secondly this is pretty easily overcome with routing hierarchy; how you structure your routes file. For example

    Route::get ('/about', [load about page])
    Route::get ('/contact', [load contact page])
    Route::get ('/{$username}', [find the user and load the page])
    

    anyone who types in

    example.com/about is going to get the about page every time. Regardless of whether a user has the name "about" or not.

  2. 2

    Ran into the same problem with https://polyl.ink, but it all comes down to how the routing hierarchy is setup. You would definitely never want one of the main app pages overridden, but having explicit routes is definitely a better option.

  3. 2

    I think anyone building a an app that relies on public URLs should do checks before performing any action.
    An example of checks:
    if (user name does name exist) -> if (user name does not consist any word from the list of prohibited words) -> if (user name does not conflict EXISTING URL) = continue (and so on).
    Instead of prohibiting certain names (which would be a security risk), you just check if the URL exist already. That solves the problem. You don't hardcode certain names as this would require you/your team to always update prohibited names (the human element, that can fail at this).
    While I am sure some people might miss those checks (including one that you've specified), I also think this is medium-level knowledge for a developer building public web app (I am not sure if the title is a clickbait, or you wrote it like this to make a point for IndieHackers).

  4. 2

    User creation should have a request validation component that checks for duplicates, reserved words (about?), obscenities, banned IPs, etc...
    Every request in an app should go throuh at least one security component that validates the request.
    Components also have their own security logic that validates the request before it reaches the business logic.
    In the routing logic, static pages are identified before usernames.
    This use case cannot happen in an application that implements good practice.

  5. 2

    STILL have a similar bug on my blogging platform. I had forgotten about it until reading your post.

    I don't separate the domain.tld of my site from the domain.tld of blogs. So, they both run off of example.com

    I have a documentation endpoint at example.com/docs. If you go to someone's blog - say blog.example.com/docs, it'll bring up the documentation page!

    Hashnode does a good job of avoiding these situations by hosting everyone's blog on a different domain.tld from their main site. I decided to be reckless and try it on one lol.

    Thanks for the reminder - I'll get this on my list!

    1. 1

      I don't know how to create different domains like username.example.com but I will have to later. I hope you fix the problem on your blogging site!

      1. 1

        ah!! I had "tried" to fix it. Realized I should have used an === somewhere instead of >. Fixed!

        Thanks again!

        As for creating the domains, I suppose it depends on your situation. For me, I added a host record in DNS for *, which points to my server's IP. So anyone's blog subdomain will follow this.

        Then in my code, I parse the host (blog.example.com), to find out what the subdomain is, and proceed from there.

Trending on Indie Hackers
💯 users 💯 days 31 comments Can you give me some feedback? 18 comments HootSuite founder Ryan Holmes discusses product validation platform Kernal 7 comments How to fight back against Google FLoC 6 comments Building in Public for the first time!😲 2 comments 4 content strategy rules I've learned the hard way 2 comments