3 replies to this topic

[bruyndoncx]

I found
Chat2: Group Chat Room with PHP, jQuery, and a Text File


on the css tricks website
http://css-tricks.com/chat2/

and wondered if this is safe to use.

the script allows you to start chatting after choosing user name, my intention is to setup a chat room for each supported language.
Conversations are saved in a text file.

I looked at the different contributions but couldn't find any other one that is this simple.
I felt it would be easy to modify it and integrate it in the sidebar of a 2.3.1 installation.

[kymation]

That page states that it has an unpatched security hole. It's a rather obvious one, so I don't think the designer knows much about security.

It stores chat data in a flat file, so that file must be writeable. I don't like using writeable files, particularly if they are where the user can discover them. Why not use the database?

An open chat room is inherently dangerous. It can be used for any purpose, including illegal transactions between users. Why do you want this, and does that justify the risk?

Regards
Jim

[bruyndoncx]

suppose the text files are in a .htaccess secured directory,
the update.php file is amended like suggested:

  //  CONSIDER THIS SECURITY MEASURE ON WHERE THE
  //  FILE CAN ONLY BE CALLED VIA AJAX AND FROM SPECIFIC LOCATIONS
  //
  // if (!isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_REFERER']!="http://your-site.com/path/to/chat.js") {
  //   die();
  // }

Also, I'm puzled why the update logic is coded with a GET request, while the other ajax actions are done through POSTS.

Can you think of a reason why this is done, can't you do through POST anything you can do through GET (and more hidden variables ...) ?

I understand your point about openness, it could be an option to only allow it  after registration on the site, but that would then create another barrier ...

[kymation]

That doesn't look like much security. My browser is set to return HTTP_REFERER set to the current site, no matter what it is supposed to be. HTTP_X_REQUESTED_WITH is just another header field and can be altered by the sender as easily as HTTP_REFERER. Checking/scrubbing the data when it's received would be a better approach.

I have no idea why it's being sent as a GET. It's somewhat less secure that way. As I said, it doesn't look like security was a consideration in the design. Caveat emptor.

Regards
Jim