30$ for help me find the bugs in my script

[tungaqhd]

This is my faucet script https://github.com/tungaqhd/CoinBox-Faucet-Script---Free-Bitcoin-Faucet-Script and there are some bugs that can let hacker attack and steal the faucethub api key stored in libs/config.php. I don't know how, it could be local attack,..... I am looking for someone can help me find and fix it. I am willing to pay 30$. Pm me if you are interested with these details:

• What is the problem ?
• How to fix it ?
• I can ask you to try on a demo site to prove.

[mocacinno]

I didn't have time to look trough your script (i just had a quick look at your index.php, without really digging into it), but the first remarks:
- you don't use prepared statements
- it doesn't look like you always clean up any user input
- it looks like you store data in local files: for example: $fp = @fopen('balance', "r");

I'd suggest by verifying ANY input you get from your user, including cookie data. I'd also suggest to stop writing to local filehandles and to start using prepared statements.

this might have nothing to do with why your script is vulnerable, it's just some general housekeeping rules: never trust any user input, use prepared statements, don't read or write to local files...

[tungaqhd]

I didn't have time to look trough your script (i just had a quick look at your index.php, without really digging into it), but the first remarks:
- you don't use prepared statements
- it doesn't look like you always clean up any user input
- it looks like you store data in local files: for example: $fp = @fopen('balance', "r");

I'd suggest by verifying ANY input you get from your user, including cookie data. I'd also suggest to stop writing to local filehandles and to start using prepared statements.

this might have nothing to do with why your script is vulnerable, it's just some general housekeeping rules: never trust any user input, use prepared statements, don't read or write to local files...

Thank you for your reply,
I am only using $mysqli->real_escape_string(var) to clean user's input and cookie, is it enough ?
And i only store faucet balance in a file for displaying purpose only, they began attack before i use it.

[mocacinno]

I am only using $mysqli->real_escape_string(var) to clean user's input and cookie, is it enough ?

Well, the consensus is to treat any data that is modifiable by the user as unsafe... That's why i would suggest to
1) check the data type... If you expect an email, use FILTER_VALIDATE_EMAIL, if you expect a number use is_numeric, ...
2) clean all the input, unless it's a variable you got from a trusted source that was previously cleaned (for example, data you fetch from your database, and that was verified and clean when it was entered)
3) start using prepared statements
4) lock down your database privileges. Make sure the mysql user entered in your config file only has the privileges he really needs to perform his tasks... If the user doesn't need "insert" privileges on a certain table, make sure he doesn't have this privilege...

And i only store faucet balance in a file for displaying purpose only, they began attack before i use it.

I'd personally suggest you just fetch this data from your database... Opening local filehandles and using system calls are always more risky (in my opinion). An attacker can use these filehandles to write code to a file, then execute it. System calls are also a common attack vector (who wouldn't want to touch files, change their permissions, cat files,...)
You could also doublecheck the owners of these php files and the folders, and the file/folder permissions...

Can you share the url where you installed this vulnerable script? I can do a quick vulnerability scan when i get home... It's usually easyer to work this way than to browse trough your sourcecode
Also, the accesslog from around the time where you were breached might be interesting information.

Once again: i didn't really dig into your sourcecode... The things i said in this post are merely good housekeeping rules i use myself when writing scripts... It's possible the attacker used a completely different attack vector