Ask coding questions

← Back to all posts
Can someone hack EekChat (again)?
tussiez (1676)

I finally got EekChat working again, and I added a few (hopefully) working anti-hack changes.
Could someone try to hack EekChat again? If my edits work, it should be impossible to change the name of the user on the client-side, as this gets overwritten by the Repl Auth.

https://eekchat.tussiez.repl.co

Comments
hotnewtop
Zavexeon (1167)

If you store anything in the cookies that you don't want changed, consider using signed cookies.

tussiez (1676)

@Zavexeon I'm not using cookies..

Baconman321 (1103)

You are able to change your username, but for some reason you can't send when you change your username...

Oh wait yeah it works, but it does override.

Hmm, my recommendation is send the username when they login and the session name. That way they can't change their name client-side. When they send the session name the server pairs that with the name associated with the session name and sends that instead of the user name that came from the client.

Keep this in mind: Always treat data that came from the client as unsafe.

However, I did cause the server to shut down by writing three backticks (probably due to unclosed markdown).

HeHe I can take the whole server offline with three characters mwA HAHAHAHAHAHAHAHAHAHAHA!!!

tussiez (1676)

@Baconman321 Yeah, when the Repl Auth is done, it sets the username in a global variable on the server, and then sets this as the username of the next person who connects. Unfortunately this breaks it when two people connect @ the same time.

A "hmm" on the triple backtick.. I'll look into that XD

Baconman321 (1103)

@tussiez You might want to try using an array instead of a global variable. It would push an object containing the session key and the username into a variable, then assign the socket connection that sent the data to that variable (via a token). If the user changes the token then they can't send the message because the token doesn't match.

While it might affect performance, generating a long token is a good idea because then the chances of a user guessing another user's token is very low. You could also generate a few more token pairs to make guessing almost impossible. In addition, you could also send the username on the client, but if it doesn't match the token sent with the token associated with that username then it won't send the message.

As for antispam, you could always send 429 error back which the client can then recognise as an antispam measure and alert the user. This would also be effective against botting (window.setInterval) at great speeds, although one could remotely set up a connection and periodically send data via CURL or fetch.

tussiez (1676)

@Baconman321 Yeah, that would make more sense
There's probably more than one way to do this, but here's one:

let names = [];
let sessionKeys = [];
//on auth
names.push(someUsername);
sessionKeys.push(Math.random()*9999);
res.sendFile('main.html?'+sessionKey);//pass session key to user

//on connect
let nm = names[sessionKeys.indexOf(userSessionKey)];//get username from session key
if(nm != undefined){
//connected
}

TBH, the server code is kinda messed up, I might as well rewrite it

Baconman321 (1103)

@tussiez I can help you @11-12 CST.
I edited my comment before so you might want to check that out. What would be cool is you had the ability to make bots and all (of course, this would be more worth it if you made the ability to set up private and public chat rooms which would take up a lot of data). Also, the profile pictures of the user isn't really working (it tries to access /undefined, which means that you probably didn't get the URL of the profile icon correctly.

tussiez (1676)

@Baconman321
1. Read it, oo
2. Yeah
3. Yee, Repl-Auth doesn't pass the PFP in the headers, you have to do a DB query, so it's undefined ATM

Baconman321 (1103)

@tussiez Yeah I'll help soon, got class now tho.