From what I understood, you won't have to register for each faucet with FaucetHub.io, only one registration for entire FaucetHub.io will be enough  |
|
|
|
How is registration going to help against bots? It's an honest question, maybe I missed something I mean, it's one thing when user has to register on each faucet. Then it doesn't make sense for bots to waste time and money creating accounts on that single faucets. But with registration on FaucetHub.io that'll change. Assuming 1000 faucets will move to FaucetHub.io, creating 10 accounts allows abusers to make 10000 claims with their bots. It doesn't help in any way. And I'm completely skipping the part where a bot for creating accounts is created, which should also be easy. It helps with monitoring malicious user(s), flagging, reversing transactions, alerting entire network about a malicious user and a lot of other things But the malicious "user" will probably be creating new accounts all the time. And all the other things you mentioned doesn't really change whether you require registration or not. You just changed the user identifier used in these action from cryptocurrency address to email address. |
|
|
|
How is registration going to help against bots? It's an honest question, maybe I missed something I mean, it's one thing when user has to register on each faucet. Then it doesn't make sense for bots to waste time and money creating accounts on that single faucets. But with registration on FaucetHub.io that'll change. Assuming 1000 faucets will move to FaucetHub.io, creating 10 accounts allows abusers to make 10000 claims with their bots. It doesn't help in any way. And I'm completely skipping the part where a bot for creating accounts is created, which should also be easy. |
|
|
|
Hi FaucetSystem,
Do we have your API links, where I can make HTTP post requests to make payments?
FaucetBox did have those.. In the dashboard I only see my API key no links or docs on API endpoints.
They use the same as FaucetBOX.com. |
|
|
|
row 160 \Session::set('lc', md5(Secure::getRandomString(10)));Its string erase answer. You can load postClaimThird with correct answer only one time. If you need receive a new correct answer - u need load postClaimSecond. I'm not convinced. That covers your "Logical captcha". What if owner disabled it and is only using reCaptcha/SolveMedia?
Please please please report security stuff in PRIVATE msg to dev please.. I don't think posting this here is a good idea..
It's too early for it to have a big impact (it was released just a few hours ago) and these are so obvious that people have to be aware that there are serious security issues with FaucetSystem.com right now. And I also think it's good to show that the admin is open for reports and fixes them quickly. It's a good PR if he handles it correctly |
|
|
|
One more thing (sorry for spam). I've checked the postClaimThird method in Guest controller, and it seems that you don't check if captcha was actually correctly solved in postClaimSecond. You don't store it in session anywhere and you don't check it in postClaimThird. That means that I can just record what request is made on postClaimThird and then send requests directly to it, skipping the postClaimSecond part. Combine that with blindly trusting user headers and I can: 1. bypass captcha 2. bypass timer (by changing to fake IP addresses) 3. bypass your antibot (by changing to fake IP addresses) I didn't test it though, so I may missed some protection, but you should take a look at this. EDIT: maybe focus on security, not features for now |
|
|
|
There's a vulnerability in your handling of IP addresses. The Ip::get() looks like this: foreach (array('HTTP_CLIENT_IP', 'HTTP_X_FORWARDED_FOR', 'HTTP_X_FORWARDED', 'HTTP_X_REAL_IP', 'HTTP_X_CLUSTER_CLIENT_IP', 'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED', 'REMOTE_ADDR') as $key){
if (array_key_exists($key, $_SERVER) === true){
foreach (explode(',', $_SERVER[$key]) as $ip){
$ip = trim($ip); // just to be safe
if (filter_var($ip, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) !== false){
if($_SERVER['SERVER_ADDR']<>$ip){
return $ip;
}
}
}
}
}
return '127.0.0.1';
You're blindly trusting headers sent by user. So I can for example do: curl --header "Client-IP: 8.8.8.8" http://somefaucet/ ...
And your script will think that the request came from IP address 8.8.8.8. Repeat that with changing the IP address and I can bypass your antibot system and your timer. Please please please buy a professional audit of all your code. If I can find such big issues in 5 minutes, people that really want to steal something will find many more.
Is adding the "ip" parameter on send is the only thing required to integrate with your AntibotInside?
Yes. It's a first phase. Second: adding statistical analysis. Thanks, we'll add it when integrating in Faucet in a BOX. |
|
|
|
|
Is adding the "ip" parameter on send is the only thing required to integrate with your AntibotInside?
|
|
|
|
What will happen to coins which will be not withdrawed until deadline? I'm sure that exist many not active addresses which didn't reached treshold, and many died faucets which have some dust on their ballance.
Depends. We never guaranteed withdrawals of coins under the threshold. If we have enough coins in the end to cover withdrawal fees for them, we may do that. But we always calculated everything under assumption that there will be no transactions with such dust outputs and recently fees dramatically increased (from ~1.5% to 3.2% currently), so I don't expect we'll be able to do that. I also think it's not a good idea to send so dusty transactions. Read the topic that's pinned in this section: https://bitcointalk.org/index.php?topic=1044399.0 : The most common problem when using faucets is the small payment. Every time you receive a bitcoin payment to your wallet you have a new input to spend at a later date. Think of this like a lump of bitcoin you can use later. When you later want to use these lumps of bitcoin they need space as part of the transaction your wallet creates for you. This is usually 180 bytes per input. A bigger (in terms of byte) transaction will need more fees in order to be confirmed in a reasonable amount of time. Each block offers only a limited amount of space (currently 1 MB) and if you need a big chunk of the space a big chunk of your available funds will be used as fee for the miners. Faucets try to counter this by creating payout limits, but they are often set very small. A reasonable fee for a transaction with less than 1000 byte in size is 10,000 Satoshi. If the payout limit is 100,000 Satoshi and you try to spend this input, you will have to spend 10% on fees. If you want an example how bad this can end, I helped someone recover from this a while back, in numbers:
~0.5 BTC from faucets, collected over ~2 years, ~2000 inputs, ~350,000 bytes, ~0.09 BTC in fees.
So such dusty transactions are more trouble then they're worth. It probably costs much more in fees to spend them then they're worth... As to old faucets - we don't even have an address that we could withdraw their balances to. That's why we give 2 months for withdrawing all coins. Everything else will be lost when we shutdown our servers. |
|
|
|
|
Random note: I'll post my semi-technical, hopefully neutral review of ePay.info, FaucetSystem.com and FaucetHub.io (when it's ready). Maybe also other microwallets if any shows up. We'll also add support for these in Faucet in a BOX (ePay.info is already supported in r66). I hope that it'll make it easier for you to select a new microwallet to transition to.
|
|
|
|
Finally a description of error codes, great! |
|
|
|
Ok!  Just please don't do this stupid voting option! FaucetBox had a lot of problems with this solution! I don't know exactly how it happened, but some faucets jump to the top of the list because of fake votes .. later it was very difficult to fix! Yea, FaucetBOX.com failed here. We shouldn't do the list in the first place, we should leave it to 3rd parties... It's pretty much impossible to keep clean automatically and we didn't have resources to moderate it manually. I'd love to see mexicantarget's solution to that.
Seems like ePay.info is going to be free: https://bitcointalk.org/index.php?topic=1149545.new;topicseen#new . Historically their service wasn't really good, but it seems it's now getting better every day, so competing with features only may not be enough if you'll be taking fees. Are you going to compete with that in any way? |
|
|
|
1. it defaults to HTTP on the website
I will totally remove HTTP Good to hear that 2. it does support HTTPS, but it's a free certificate from CloudFlare, so I bet they're using the "Flexible SSL" setting. That means that connection is only encrypted between you and CloudFlare, but then it's unencrypted plaintext between CloudFlare and FaucetSystem.com servers.
FULL, but self-signed That's only a little bit better. Please use a valid certificate and "strict" option on CloudFlare. You can get free, really nice certificate from LetsEncrypt. 3. they use HTTP endpoints in their libs for migrating Faucet in a BOX script
solved There are still some problems here. 1. " http://faucetsystem.com/check/" instead of " https://faucetsystem.com/check" is used as a base for balance check for users 2. in "update_faucetinabox_r66_plus" you set 'verify_peer' => false in services.php. That breaks all security, you can just as well use plain http. What's more, setting it like that in services.php means that it applies to all services, not just your FaucetSystem.com! 4. their login form is vulnerable to brute-force attacks
5. no password reset?
6. "I agree to terms and conditions" checkbox, but there's no link to terms anywhere
7. fees for users (not just owners deposits), that doesn't seem to be mentioned anywhere on the site, only here on forum
Several days and im fixing it 8. there are CSRF vulnerabilities on all forms! That's critical! It means that if someone can compell you to click anything on a random site while you're logged to FaucetSystem.com, they can do pretty much any action on your account. Imagine that someone asks you to check his faucet, you click "Claim" on their faucet and suddenly API keys of all your own faucets are disabled! I think that only password changing is protected (as it requires providing old password).
solved Thanks, Kazuldur. Nice! . With CSRF fixed we'll probably add FaucetSystem.com support officially in next Faucet in a BOX version EDIT: Seems like ePay.info is going to be free: https://bitcointalk.org/index.php?topic=1149545.new;topicseen#new . Are you going to compete with that in any way? |
|
|
|
This is really nice ASN list, you may also want to block the digitalocean and other vps providers. But using a nastyhosts service seems to be problematic, as I see. If my home IPs (3 different tried) are marked as nasty there then could be a lot of IPs in their database that actually are honest people using. I think the better option to block whole ASNs is to use cloudflare service and get rid of VPS ISPs etc. But the most interesting question is.. What is the purpose to use antibotlinks if they are not secure (and people dont like it) Can you PM me your home IPs? I'll see what network they're from and unban them in NastyHosts if they're good |
|
|
|
EDIT:
my faucet is selfmade can you give me some startup how to send a payment with your api ?
$pay = new FaucetSystem($api_key, $currency);
$pay ->send($to, $user['balance']);
Replace 'faucetbox.com' by 'faucetsystem.com' in your scripts and enjoy. where to edit faucetsystem.com  ? iam using this for faucetbox payments $pay = new FaucetBox($api_key, $currency);
$pay ->send($to, $user['balance']);and they provided a php class for this .... can i use the same class ?=? can you explan a bit more i dont understand how to implement your system. kind regards Open the faucetbox.php file that you got from FaucetBOX.com and replace all "faucetbox.com" text in that file with "faucetsystem.com". |
|
|
|
We'll add a simple GET link too.
Crappy hostings that use even crappier proxies to save bandwidth will probably cache GETs like that. It's and edge case, but may happen. what is the Problem with this php method [snip] Maybe he's not using PHP ? |
|
|
|
|
Here are my problems with FaucetSystem.com in it's current form:
1. it defaults to HTTP on the website
2. it does support HTTPS, but it's a free certificate from CloudFlare, so I bet they're using the "Flexible SSL" setting. That means that connection is only encrypted between you and CloudFlare, but then it's unencrypted plaintext between CloudFlare and FaucetSystem.com servers.
3. they use HTTP endpoints in their libs for migrating Faucet in a BOX script
4. their login form is vulnerable to brute-force attacks
5. no password reset?
6. "I agree to terms and conditions" checkbox, but there's no link to terms anywhere
7. fees for users (not just owners deposits), that doesn't seem to be mentioned anywhere on the site, only here on forum
8. there are CSRF vulnerabilities on all forms! That's critical! It means that if someone can compell you to click anything on a random site while you're logged to FaucetSystem.com, they can do pretty much any action on your account. Imagine that someone asks you to check his faucet, you click "Claim" on their faucet and suddenly API keys of all your own faucets are disabled! I think that only password changing is protected (as it requires providing old password).
I wouldn't use that if I were creating a faucet.
|
|
|
|
Holy crap, excellent feature. I've never been a faucet admin before, but did FaucetBox offer this security feature before?
FaucetBOX.com provided this ACL feature too. Good to see it will be at FaucetHUB.io also. I'm open for suggestions If there's more security features needed, I could add them. Random ideas: 1. Email notification on login 2. Option to restrict login to specific countries 3. Email confirmation when someone tries to login from another country than usual (so it's not possible to login from a new country without clicking link in email) |
|
|
|
Okay, here's what I've been working on lately.
-snip- no DOGE and DASH visible? Let's assume that a server costs around 10-30 dollars to host a daemon. What do you think, would the site be able to cover the expensesfor the server/fees? ;p That's the main issue with low demand coins  (Wont be adding DASH for a long time) good point. what about etherum? i would imagine there would be a higher demand for that. i saw several people ask in the faucetbox thread. I'm not sure at this point. I'll just need bitcoin wallet for my own sites, so I'm trying to focus on that one only If there's enough demand and fees can pay for the server, I wont mind adding any altcoin options. Last time I've checked Ethereum doesn't support Bitcoin Core's JSON-RPC API, which probably increases the cost of integrating it in your system. |
|
|
|
|
Show Posts
