Like Tree5Likes

Cage scheduler hacked!

This is a discussion on Cage scheduler hacked! within the Tech Board forums, part of the Community Boards category; I have written some html, css, php and javaScript to develop a scheduler for football matches. Web development is not ...

  1. #1
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,681

    Cage scheduler hacked!

    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!
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,720
    Quote Originally Posted by std10093
    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).

    Quote Originally Posted by std10093
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Epy
    Epy is offline
    Fortran lover Epy's Avatar
    Join Date
    Sep 2009
    Location
    California, USA
    Posts
    963
    Crack is the word you're looking for, not hack. There's a difference.

  4. #4
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    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.

  5. #5
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    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.
    Last edited by Cat; 03-07-2014 at 11:19 PM.
    stevesmithx likes this.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  7. #7
    and the hat of copycat stevesmithx's Avatar
    Join Date
    Sep 2007
    Posts
    498
    Quote Originally Posted by std10093 View Post

    -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.
    cyberfish likes this.
    Not everything that can be counted counts, and not everything that counts can be counted
    - Albert Einstein.


    No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes.
    - Herbert Mayer

  8. #8
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,720
    Quote Originally Posted by stevesmithx
    Seeing entries like "--'DROPTABLEplayers" makes me suspicious
    Nah, just me trying simple SQL injection to check.
    cyberfish likes this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #9
    and the hat of copycat stevesmithx's Avatar
    Join Date
    Sep 2007
    Posts
    498
    Quote Originally Posted by laserlight View Post
    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.
    Not everything that can be counted counts, and not everything that counts can be counted
    - Albert Einstein.


    No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes.
    - Herbert Mayer

  10. #10
    Registered User Hodor's Avatar
    Join Date
    Nov 2013
    Posts
    650
    Quote Originally Posted by Cat View Post
    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

  11. #11
    Registered User Hodor's Avatar
    Join Date
    Nov 2013
    Posts
    650
    Quote Originally Posted by laserlight View Post
    Nah, just me trying simple SQL injection to check.
    Hope you backed up his site for him first

  12. #12
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,681
    Quote Originally Posted by Epy View Post
    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).

    Quote Originally Posted by laserlight View Post
    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.

    Quote Originally Posted by Elysia View Post
    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!

    Quote Originally Posted by Cat View Post
    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).

    Quote Originally Posted by stevesmithx View Post
    Have you guarded your code against SQL injection attacks?
    No, I haven't.

    Quote Originally Posted by Hodor View Post
    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
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  13. #13
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Quote Originally Posted by std10093 View Post
    ...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:

    Code:
    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?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    SAMARAS std10093's Avatar
    Join Date
    Jan 2011
    Location
    Nice, France
    Posts
    2,681
    >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:
    Code:
    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).
    Code - functions and small libraries I use


    It’s 2014 and I still use printf() for debugging.


    "Programs must be written for people to read, and only incidentally for machines to execute. " —Harold Abelson

  15. #15
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Quote Originally Posted by std10093 View Post
    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?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. brainstorming with a scheduler.
    By seemaxie in forum C Programming
    Replies: 2
    Last Post: 12-05-2012, 09:36 AM
  2. problem with the scheduler
    By ushacy in forum C Programming
    Replies: 3
    Last Post: 09-20-2011, 05:52 AM
  3. scheduler in linux
    By anjana in forum Linux Programming
    Replies: 6
    Last Post: 05-29-2007, 12:59 AM
  4. new scheduler in linux
    By anjana in forum Linux Programming
    Replies: 1
    Last Post: 05-28-2007, 02:55 AM
  5. we of the cage
    By mithrandir in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 08-21-2002, 10:14 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21