Jump to content

[SOLVED] security testing


Ninjakreborn

Recommended Posts

I didn't know whether to post this in here, or in website critique.  I don't want a critique, just security advice.  I have found substantial loopholes in hte coding ( variables not being cleaned at all, variables passed straight into queries unsanitized (on every page), I am getting started fixing that.

 

I was wondering if someone can help me point out other security issues.

The system was hacked, multiple times.  People kept getting into user accounts, and emptying there banks, as well as other things.  I am trying to beef up security as much as possible, also any advice on some good way's to really beef up security on this specific site would be appreciated.  I have a few things I am goign to do (login limit (3 times before 24 hours banning), captcha's on login to help discourage brute force), those are some ideas I am entertaining right now.

 

I am also cleaning all variables site wide (huge job), as well as some other stuff.

 

{link removed at request of user}

 

That is the url

Thanks for the help, and security advice.  If this should be in critique's, then please move it there, but this wasn't really a critique.  it was more of a security test.

Link to comment
Share on other sites

Ok, any more really hard tests would be appreciated.  I understand the issue with variables (sitewide) not being cleaned, and I intend to fix that, but there are a lot of variables and a lot of celaning to do.  Most of them are passed straight into queries.  If anyone else want's to do what they can, it's appreciated.  I told him there would be multiple testers going through the site, trying to find security issues, so anything that anyone can uncover wuold help a lot.  Thanks so far.

Link to comment
Share on other sites

Force only one login per user at a time; a lot of exploits in those games comes from someone logging in with two separate web browser applications and entering almost simultaneous requests.

 

I would also turn off directory browsing; no telling what kind of information can gather from see the directory structure on the web. *snip*

I'm not registered so I have no idea what kind of information I could pull after being a user and actually logged in.

 

EDIT: link removed at request of OP.

Link to comment
Share on other sites

Force only one login per user at a time; a lot of exploits in those games comes from someone logging in with two separate web browser applications and entering almost simultaneous requests.

 

I would also turn off directory browsing; no telling what kind of information can gather from see the directory structure on the web.  Example:  @@@####@

I'm not registered so I have no idea what kind of information I could pull after being a user and actually logged in.

Perfect, both of those will be fixed.

 

However there is one thing happened that is causing this.  THere is one user that has gotten into the site.  One user that got into the site, that caused a problem  He has been getting into other people's accounts and transferring money from there account to his.  Based on what the admin says he has gotten into a total of 8 accounts so far.  He will continue unless I figure out what he is putting in there.

Link to comment
Share on other sites

Small piece of advice, try getting your point across in as few words as possible; people are more likely to hang around and read your questions when there's less to read!

 

"However there is one thing happened that is causing this.  THere is one user that has gotten into the site.  One user that got into the site, that caused a problem  He has been getting into other people's accounts and transferring money from there account to his.  Based on what the admin says he has gotten into a total of 8 accounts so far.  He will continue unless I figure out what he is putting in there."

 

Translation:  The admin informs me there is at least one user who has accessed a total of 8 accounts and uses them to transfer game-money into his own account.

 

The best solution I can think of would be to do the following:

 

1)  Keep a DB record of user logins.  For each user on every login, record the current time and their IP address.  Enable a cron job to clean this every 30 or 45 days because its doubtful you'll need to view records that far back.

 

2)  Enable another cron job that inspects the data and notifies the site admin, via website message when they log in, email, etc. of suspicious behavior.  Suspicious behavior in this case would be multiple accounts constantly logging in from the same IP address and transferring money to / from each other.  You can use this information to suspend or ban accounts that appear to be cheating.  However, keep in mind that people also play from within the same household.  If there's two accounts that always log in from the same IP address, its probably multiple players within a single home.  If there's two accounts and they have a consistent record of logging in from different IPs, yet occasionally one of the accounts is accessed by the IP from the other account and you can trace the accounts to, let's say, Florida and New York, that might be a case of a hacked account.

 

3)  Every user, after logging in, should be displayed with a message indicating their last login, including time and IP.  You could even modify this information to be savvy enough to report to users when there exists login behavior that appears suspicious with their account.

 

 

Link to comment
Share on other sites

Ok, I turned off directory access.  I am going to follow all advice on here and heavily work on securing that login.

1. Making accounts validate the email

2. Building login captcha

3. Do the recording/restrictions that were altered here

4. Clean variables (critical areas, it's a huge site)

 

Hopefully once these issues are spoken out, and fixed, this will remove the hacking.

 

He has also mentioned about shutting the site down, so I hope he doesn't have high level access I was not aware of.

Link to comment
Share on other sites

So should this be the time when I pick up where I left off with Mcrypt.  i was trying to understand the keys awhile back, is this going to be the situation where I need to start using it again.

Or is there something lighter I can trust more for a site that is going to have someone tryign there hardest to hack it.  He has already gotten pretty drastic with it at this point.  I am sure he would do anything to try and get access to anything on the site he wasn't suppose to, so the utmost security has to be set in place. I am preparing a list of things that need to be done and presenting them to the client.

 

1. Remove directory access, in escence turn off directory listings.  I have done this already, it has already been completed.  This will severely lower the chances of someone getting access to information they should not be getting access too.  This is something I have already done.

 

2. Turn register_globals OFF, it need's to be cut off.  This need's to be done, however it's not reading my custom ini file's.  I need access to the main directory so I can turn this off.

 

3. Install captcha for login area - let me know ifyour programmer is doing this, or if you want me to do this.

 

4. Require email validation when registered - let me know if your programmer is doing this, or if you want me to do this.

 

5. Clean all variables on the site - they need cleaned, and secured.  Tell me if you want

 

Note: this is the most important thing.  They need to be cleaned drastically, I went over every page on the website and they are ALL unclean.  This is a very, very big issue.

 

6. Put the following restrictions into place for user's loging in

a. Only allow a user to log into 1 account at a time

b. Only allow them to try 1-3 time's before they are temporarily banned for 24-48 hours

c. Get the ability to ban user's signing up based on (account, username, emailaddress, and ip), this will allow you to cut down the issues drastically over the period of about a week.

d. Compare logins. Keep track of login attempts by ip.

 

This is a list of what I have, from here I am going to expand on the list and present it.  Hopefully this will be everything almost.

Link to comment
Share on other sites

Thank you for the advice.  based on all the advice I have recieved here, and thanks to all the inspiriation I was able to create a pretty good list.  I am pretty sure this will greatly limit the vunerabilities that exist on the site.  If some admin, could be so kind as to just eliminate that url that is listed in this above.  I want to remove all entries to the site, I just wanted it up there temporarily to get some help.  Again thank you all for the wonderful advice.  I think I have enough to get this as secured as I can.

 

SOLVED

Link to comment
Share on other sites

Hey, busi, before you close up shop for the day, you may want to check this out: go to the following page in the forum: http://www.example.com/forums.php?view=topic&t=1 and go to page 7... Apparently, your forum is open to XSS attacks. I was able to insert some javascript on the page that echoes out the user's session cookie... not good.

 

edit changed original URL at request of OP

Link to comment
Share on other sites

Hmm, thanks a lot for finding that.

I just happened to come back and check this post.  I will go ahead and relay the message to him, I am having him call me, I will explain how and why that is an issue.

Get him to set some stuff in place to fix it.

Thank you for the feedback.

Link to comment
Share on other sites

1)  Keep a DB record of user logins.  For each user on every login, record the current time and their IP address.  Enable a cron job to clean this every 30 or 45 days because its doubtful you'll need to view records that far back.

 

There are a few reasons why I think you are talking about session hijacking (if you arnt there are a few reasons why I think this would only be useful for session hijacking. But a better solution is to store the following session data

 

$_SESSION['expire_time'] //gets updated each time you load a page and is compared against the time()

$_SESSION['user_agent'] //holds the web browser info if someone has the same session on a different browser its probably a hack

$_SESSION['user_ip'] //compare the ip to the $_SESSION['ip'] if it is set

 

if any of the above information changes between requests just delete the session. regenerating the session ids each time they view a page also helps

 

you said it was a big job to fix your site, try to bring stuff to a central point

 

I loop through all $_COOKIE, $_REQUEST, $_GET, $_POST data and validate it, I convert the strings that are numeric to integers and clean the data. Try to bring all your code to central points so that you can maintain it easier. as well as letting you do more with less code.

 

if you use prepared statements when doing database queries it will be impossible to do sql injection (I recommend using PDO)

 

c. Get the ability to ban user's signing up based on (account, username, emailaddress, and ip), this will allow you to cut down the issues drastically over the period of about a week.

 

You do not need to ban all these things, just ban the user_id. you should be using constraints in your database combined with validation in your registration script to make sure each email address and username is unique. But yes banning ips as well as accounts is also a good move as not everyone you want to ban will have or be using an account.

 

there has been some talk about not letting a user be logged in via multiple accounts there are various reasons why you should not do this, I have a laptop and a desktop pc i switch between them often if i did this i could get banned as i always tick the remember me button on sites

 

and last but not least, record each page view and what user_id viewed the page along with their ip address if you do this you can create functions to easily allow you to see how often users view a specific page when they logged out, when they logged in, what areas a user likes, what areas they dont like and the data can be used for many reasons as well as helping identity problem users also when you do this you should record the request uri if someone is requesting pages that are not linked to multiple times in a way that is clearly offensive it will allow you to look at the logs or use some kind of automation to spot it and ban them

 

 

 

 

Link to comment
Share on other sites

Take it into consideration though, about 95% use XSS hijacking methods for GET methods, so if your using POST methods you should be okay.  Also if you store your session variables without using cookies that helps too.  I won't go into too much detail as this is not a hacking forum, if you want more of that check out the cult of the dead cow =P.

Link to comment
Share on other sites

Take it into consideration though, about 95% use XSS hijacking methods for GET methods, so if your using POST methods you should be okay.  Also if you store your session variables without using cookies that helps too.  I won't go into too much detail as this is not a hacking forum, if you want more of that check out the cult of the dead cow =P.

 

While this is technically true, it's extremely easy to run XSS hijacks on POST methods, too, especially with the tools that are available that override some of the server side restrictions put on user forms and such. That's actually how I discovered the XSS vulnerability in this forum. I agree with the comment about not storing session variables in a cookie unless absolutely necessary (which it is for some optional features at times).

Link to comment
Share on other sites

Ted: He just wants to check the security of his site and Obisidian detected that his site was susceptible to XSS Hijacking.  Fully preventing XSS hijacking is almost impossible.  If you have some type of proxy software that can intercept the request theres no way really around that.  Generally though if you use GET request you are going to be hit more often that is for sure.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.