CapFriendly: all profiles exist

[AlexIsOK]

Checklist

• [x] I'm reporting a website that is returning false positive results
• [x] I've checked for similar site support requests including closed ones
• [x] I've checked for pull requests attempting to fix this false positive
• [x] I'm only reporting one site (create a separate issue for each site)

Description

all capfriendly profiles are marked as existing. for example: https://www.capfriendly.com/users/thisuserdoesnotexist-aasdfgahsfdhgafshdgfasghfdghasfd

enter any value and it will display an active user. not sure if this is an issue with the site, but the join date for accounts that cannot possibly exist is between 2015-2019 (from what i saw).

this might be an anti-scraping tactic as well, not 100% sure.

[AlexIsOK]

i can confirm this is an anti-scraping tool. after checking for a user that does not exist with a join date in 2019, i created an account with that username, and the member since field was updated to today.

[Walter-o]

Would maybe be an improvement if a hit on a site like this would have an asterisk in the front instead of a + like a real hit.

[AlexIsOK]

Would maybe be an improvement if a hit on a site like this would have an asterisk in the front instead of a + like a real hit.

that seems too subtle imo, people probably wouldn't notice the difference.

[Fiachaire]

I've been trying to understand this behavior as well. It seems like instead of a standard 404 they're pretending the account does exist. And when you created an account in the same name it didn't replace an account it replaced the 404 mask. If instead of creating the account you try to say you forgot the password it will tell you no such account exists.

What I want to know is has the site put itself at risk doing this instead of using the normal static 404? These fake dynamic responses persist over multiple browsers/devices. I'm only starting out as a student but I've been trying to figure out why this isn't a massive vulnerability for them.

[AlexIsOK]

I've been trying to understand this behavior as well. It seems like instead of a standard 404 they're pretending the account does exist. And when you created an account in the same name it didn't replace an account it replaced the 404 mask. If instead of creating the account you try to say you forgot the password it will tell you no such account exists.

What I want to know is has the site put itself at risk doing this instead of using the normal static 404? These fake dynamic responses persist over multiple browsers/devices. I'm only starting out as a student but I've been trying to figure out why this isn't a massive vulnerability for them.

they could use the username in a seed to generate random numbers for the join date, favorite team, etc.

they probably aren't storing the fake profile data anywhere, it's generated when you view the page. it's probably being done as an anti-scraping tool or to protect their users privacy.

edit: to add on, there is no vulnerability here that i can see

[Fiachaire]

The date and teams are randomly generated but your saying their persistence is directly tied to the names? Is there a way to test this? I'll have to read up on how this functions as an antiscraping tool, particularly as the site is all about compiled data.

[AlexIsOK]

The date and teams are randomly generated but your saying their persistence is directly tied to the names? Is there a way to test this? I'll have to read up on how this functions as an antiscraping tool, particularly as the site is all about compiled data.

i have no way of knowing if this is true or not, but it seems like the most simple way.

take this java code:

String username = "noonewouldeverusethis";
Random r = new Random(username.hashCode());
System.out.printf("year joined: %d%n", r.nextInt(2020 - 2010) + 2010);

this will produce the same year as long as the username is the same. it would be very simple to pick from an array of team names to determine their team.

[Fiachaire]

Would the usernames not be scraped/filtered by running them through password reset and recording which of the two responses was triggered?

[AlexIsOK]

Would the usernames not be scraped/filtered by running them through password reset and recording which of the two responses was triggered?

1. the website does password reset through email
2. i don't think github would like a repo automating password reset forms, seems kind of malicious
3. even if it was by username, they could put measures in place to prevent anti scraping things as well

so it turns out you can reset by username, but if the username exists, it'll send an email to the person who owns the account asking for a password reset.

[sdushantha]

False positives cannot be seen from CapFriendly anymore. Feel free to create an issue if this happens again