Cage scheduler hacked!

[std10093]

I have written some html, css, php and javaScript to develop a scheduler for football matches. Web development is not my field.

Everybody should use it simply. The problem is, that some people (I suspect from my uni, that I study CS), go to the page and delete/insert players/matches for "fun". :/

I have made some kind of password, but once someone clicks one page source, it is pretty easy for him to see the password. As far as I know, I can't hide the code that runs in the client.

The password goes like this: When the user clicks on the Delete Match button, a pop-up window arises, the user types the password and with a simple js password I check if it is ok. In this function, the "hacker" can see the password!

You see, this is not my field, so I asking for a simple and fast solution, which will provide some security to my site, so that it is not trivial to be hacked by a programmer. Since people do this for "fun", they won't (I hope) try hard to hack it.

Cage scheduler. I have scheduled a match, for testing ( the players are notified that the site is "out of order" ).

-I was checking my post and he hacked it again! He didn't hack the password this time (he used functions that do not need a password, but he did something I haven't provided the code for. The idea is that the user clicks on a name from the rightmost list and the name is inserted in the match. He has managed to overwrite the players' names on the match <- I haven't written the code for this!)

A login would be the ideal for me, since the players must use the site with 100% easy-ness. For example, something like this, but with the password hidden!

[laserlight]

I have made some kind of password, but once someone clicks one page source, it is pretty easy for him to see the password. As far as I know, I can't hide the code that runs in the client.

The password goes like this: When the user clicks on the Delete Match button, a pop-up window arises, the user types the password and with a simple js password I check if it is ok. In this function, the "hacker" can see the password!

It sounds like you need to implement an authentication system such that each user has their own account and can only edit their own schedules. If you want to stick to a simple single password method, then use HTTP Basic authentication (but of course this won't help if the "hacker" is a prankster among your group of otherwise trusted friends).

He didn't hack the password this time (he used functions that do not need a password, but he did something I haven't provided the code for. The idea is that the user clicks on a name from the rightmost list and the name is inserted in the match. He has managed to overwrite the players' names on the match <- I haven't written the code for this!)

It looks like your code merely accepts whatever is sent without validating the input with the serverside data, so one can edit a name on the list, insert it, save, and it is whatever I want it to be.

[Epy]

Crack is the word you're looking for, not hack. There's a difference.

[cyberfish]

There is no (easy) way to do secure authentication on the client side.

One way to make it more annoying to crack (but definitely still possible) is to encrypt the submission code. Have the user type a password, generate a key from the password to decrypt it, then eval() it. But that's really just security by obscurity (ie. the wrong way).

That's a lot more work and still much less secure than server side authentication, though.

[Elysia]

Consider also that when dealing with passwords, you should use a secure connection (i.e. https); otherwise, a hacker can see your password as it travels across the web.

[Cat]

The first rule of web development: The server cannot trust the client.
The second rule of web development: The server cannot trust the client.

Password validation should never be done client-side. Do it server-side.

In fact, ALL input validation needs to be done server-side. Client-side validation is for usability (you can tell the user the value is wrong without the time of a server trip). Server-side validation is for actually doing things with the data. Passwords can never be validated on the client side because, as you see, it leaks the password.

It's very easy for a knowledgeable person to not only look at your javascript, but edit and change the javascript running in their browser however they see fit. If your password checking is in Javascript, I could easily bypass it altogether, even if I still want to run other portions of your scripts. Not only can I change any Javascript, I can change any piece of data in my web browser - including adding, deleting, or modifying DOM nodes without using your JS functions.

In looking at your code, if I wanted, I could easily pass any data I wanted to your PHP scripts, even without touching logins. Without testing the security of those scripts I can't say just how badly I could muck things up if I tried, but actually doing so is trivially simple. Your PHP scripts need to treat every piece of data as though it were toxic until you have proven otherwise.

If there are things that shouldn't be changeable by the user (like the names in the matches), then the server shouldn't even accept that data from the client under any circumstance. The password is only one of the problems - you're treating data from the web client as trusted, and that's the core mistake. Every single piece of state, every function, every variable on the web client is accessible and modifiable just using the tools embedded inside a modern web browser.

[stevesmithx]

-I was checking my post and he hacked it again! He didn't hack the password this time (he used functions that do not need a password, but he did something I haven't provided the code for. The idea is that the user clicks on a name from the rightmost list and the name is inserted in the match. He has managed to overwrite the players' names on the match <- I haven't written the code for this!)

Have you guarded your code against SQL injection attacks? Seeing entries like "--'DROPTABLEplayers" makes me suspicious that you may have been exploited by the mom.
https://www.owasp.org/index.php/Main_Page is a good place to start to make your web applications more secure.

[laserlight]

Seeing entries like "--'DROPTABLEplayers" makes me suspicious

Nah, just me trying simple SQL injection to check.

[stevesmithx]

Nah, just me trying simple SQL injection to check.

I had slight doubts that someone in this board might be pen testing for the OP.. ;-) Still not a bad idea I suppose for the OP to check for this possibility.

[Hodor]

The first rule of web development: The server cannot trust the client.
The second rule of web development: The server cannot trust the client.

[...]

It's very easy for a knowledgeable person to not only look at your javascript, but edit and change the javascript running in their browser however they see fit. If your password checking is in Javascript, I could easily bypass it altogether, even if I still want to run other portions of your scripts. Not only can I change any Javascript, I can change any piece of data in my web browser - including adding, deleting, or modifying DOM nodes without using your JS functions.

In looking at your code, if I wanted, I could easily pass any data I wanted to your PHP scripts, even without touching logins. Without testing the security of those scripts I can't say just how badly I could muck things up if I tried, but actually doing so is trivially simple. Your PHP scripts need to treat every piece of data as though it were toxic until you have proven otherwise.

[...]

And note: https will not help you here. If my browser can read (decrypt) the source (it has to), so can I

[Hodor]

Nah, just me trying simple SQL injection to check.

Hope you backed up his site for him first

[std10093]

Crack is the word you're looking for, not hack. There's a difference.

At this moment, this doesn't seem to be much of a concern to me (however, you are probably right).

It sounds like you need to implement an authentication system such that each user has their own account and can only edit their own schedules. If you want to stick to a simple single password method, then use HTTP Basic authentication (but of course this won't help if the "hacker" is a prankster among your group of otherwise trusted friends).


It looks like your code merely accepts whatever is sent without validating the input with the serverside data, so one can edit a name on the list, insert it, save, and it is whatever I want it to be.

I am pretty sure it's someone from my uni (I do not think it's a guy from the Cage). But yes, I have no proof.
Yes, there is no validation, since when I wrote the code, I assumed that there would be no "bad" users. I mean, it's just a scheduler for a football pseudo-league, which is played somewhere, that it is not even built for playing football. What I mean. it's not a big site or something. The person(s) who did this, must has really a lot free time.

Consider also that when dealing with passwords, you should use a secure connection (i.e. https); otherwise, a hacker can see your password as it travels across the web.

We did that on the networks lab in first semester, you are right!

The first rule of web development: The server cannot trust the client.
The second rule of web development: The server cannot trust the client.

Password validation should never be done client-side. Do it server-side

In my case, they trust each other, which causes the problem. But as explained above, when the question arised in my head: "What about security?", I answered, come on now..it's just a Cage scheduler! I tried doing it in server-side, but I has some code erros (I do not remember them now).

Have you guarded your code against SQL injection attacks?

No, I haven't.

Hope you backed up his site for him first

I deleted the matches and it seems to be ok. Moreover, I fully trust laserlight.

Well, I figured out how one could write arbitrary names in the matches. The scheduler can "remember-save" two matches. Every match is saved in .txt. However, in order the scheduler.php to be able to modify the .txts, I had to change the permissions of them.
-rw-r--rw- 1 std10093 undergr 1 Mar 8 16:16 match1.txt
So if he can (I do not know if this is possible) modify the .txt, then here is the brik.

Thank you all for your answers, but this doesn't seem to be something trivial to be solved and I do not have much time now (I have a project deadliny by Monday and at Tuesday, I fly to Inria, France). So, what I will proabably do, is to keep the scheduler out of scope and schedule the match with the traditional methods, until the crackers get bored. :P

[Elysia]

...The person(s) who did this, must has really a lot free time...

Not really. Took me under a minute to figure out your password and how to totally mess with your little system. This line says it all:

if(slot == 1) $.post('http://cgi.di.uoa.gr/~std10093/scheduler_file_write.php', {elements: elements});

Your system is so inherently insecure that any programmer with a little knowledge can screw it up. You don't need lots of free time

Some security tips:
- Never expose read/write APIs to the client. And if you absolutely and truly must, then you should implement a password system first. You are screaming for a beating if you leave these things unexposed.
- Never validate passwords client-side. It took me under a minute to find your password. Sure, you can obfuscate it, but I can still prettify it and find your password. Storing the encrypted password is much safer, but again, the fact that you are doing the validation client-side means that a hacker can just bypass the check.
- Never expose any database or SQL client-side. It gives the hacker more information about your system.
- Never concatenate SQL with data from the user. You should use parameter binding. This greatly reduces chances of SQL injection.
- Never send any passwords or any other dangerous information (e.g. session state) over an unencrypted connection. To save yourself some headache, the best option is to always use HTTPS, because why not?

[std10093]

>Not really. Took me under a minute to figure out your password and how to totally mess with your little system.
I don't mean that. There were several attacks time by time, so I mean that they check back again and again. However, I might be wrong, since they might be different people.

>This line says it all:

if(slot == 1) $.post('http://cgi.di.uoa.gr/~std10093/scheduler_file_write.php', {elements: elements});

Why?

>HTTPS, because why not?
I do not know to do that. (I am not asking someone to show me).

[Elysia]

Why?

Because you are essentially putting a sign saying:
"Here server, write this data I am sending you to my file."
Incredibly easy to spoof what I'm sending to that script.
It's the same as taking input directly from a desktop program and writing it as-is to a file.

I do not know to do that. (I am not asking someone to show me).

A word is missing... do you mean to say you don't know how to do that?