EmpireCoin: Bug bounty program

[BilalHIMITE]

Another SQL Injection is detected in "get_session.php" line 15.
$session_key is not escaped.

[NLNico]

TBH your whole code looks like a lot of security risks. I thought about making a proper list of vulnerabilities, but this would require a lot of time from me (since your site does look complex) and the bounties look a bit "uncertain". So I am not sure if I want to put like a few days of time into it TBH.



Just in general you REALLY should adjust this:

* NEVER ever use the "quote()" shit for protection of SQL injection. Use prepared statements (lookup PDO->prepare()) instead.
* Use CSRF protection probably just ALWAYS whenever there is user input. I am pretty sure I can steal the escrow coins by sending the escrow an URL that loads an iframe/post-form/etc to send the coins to me. This requires user interaction (escrow has to open an URL), but can be pretty easy/doable.
* IMO you shouldn't strip_tags before putting it in the DB. Just always sanitize the output to the user. A template system can help with this, some will HTML encode every variable by default.
* Best to make most scripts NOT public for visitors to access. Basically you should only have .htaccess + bootstrapper (index.php) in your public_html together with CSS/JS/images. All PHP should be outside of it and just loaded by index. In your situation, you could at least hide the cron/classes/includes/libs/scripts. For example I can get your RPC password here: http://empirecoin.org/scripts/getinfo.php That is probably some test file which you forgot to delete (and I assume the bitcoind is not running at the moment), but could be serious problem.
* Just in general your code would be much easier to read (= easier to see bugs) if it's divided into MVC structure.
* Functions like rand() and mt_rand() are not cryptographically secure. It is possible to hack accounts on your site by using the "reset password" function and cracking mt_rand. Search for random_bytes() - I believe that is cryptographically secure in PHP lately.

All of those things, are generally taken care of by a PHP framework. That is why using a PHP framework is pretty great. I really like Laravel lately. But converting your site to a PHP framework might take serious time.



On the positive side: it seems to have a lot of features and I can always appreciate open-source work.

Another SQL Injection is detected in "get_session.php" line 15.
$session_key is not escaped.

I am pretty sure session_id() verifies any session ID from cookie etc? I don't think you can get values with " with that. OP should still use prepared statements though.

[joey.rich]

Would it not be a lot cheaper and maybe more safe if you try to hire a professional service for this?

I could be wrong but i think it's really the best and even quicker option since they also offer to fix the issues!

Because what if someone really find a big hole and he will keep it and not tell you, and then use it once there is a lot cash to steal?

Since this is already open source, I don't see any additional risk from asking people here to check for flaws.

If vulnerabilities are found, multiple people should find it; therefore each person has incentive to be the first to report & claim the bounty.

[joey.rich]

TBH your whole code looks like a lot of security risks. I thought about making a proper list of vulnerabilities, but this would require a lot of time from me (since your site does look complex) and the bounties look a bit "uncertain". So I am not sure if I want to put like a few days of time into it TBH.



Just in general you REALLY should adjust this:

* NEVER ever use the "quote()" shit for protection of SQL injection. Use prepared statements (lookup PDO->prepare()) instead.
* Use CSRF protection probably just ALWAYS whenever there is user input. I am pretty sure I can steal the escrow coins by sending the escrow an URL that loads an iframe/post-form/etc to send the coins to me. This requires user interaction (escrow has to open an URL), but can be pretty easy/doable.
* IMO you shouldn't strip_tags before putting it in the DB. Just always sanitize the output to the user. A template system can help with this, some will HTML encode every variable by default.
* Best to make most scripts NOT public for visitors to access. Basically you should only have .htaccess + bootstrapper (index.php) in your public_html together with CSS/JS/images. All PHP should be outside of it and just loaded by index. In your situation, you could at least hide the cron/classes/includes/libs/scripts. For example I can get your RPC password here: http://empirecoin.org/scripts/getinfo.php That is probably some test file which you forgot to delete (and I assume the bitcoind is not running at the moment), but could be serious problem.
* Just in general your code would be much easier to read (= easier to see bugs) if it's divided into MVC structure.
* Functions like rand() and mt_rand() are not cryptographically secure. It is possible to hack accounts on your site by using the "reset password" function and cracking mt_rand. Search for random_bytes() - I believe that is cryptographically secure in PHP lately.

All of those things, are generally taken care of by a PHP framework. That is why using a PHP framework is pretty great. I really like Laravel lately. But converting your site to a PHP framework might take serious time.



On the positive side: it seems to have a lot of features and I can always appreciate open-source work.

Another SQL Injection is detected in "get_session.php" line 15.
$session_key is not escaped.

I am pretty sure session_id() verifies any session ID from cookie etc? I don't think you can get values with " with that. OP should still use prepared statements though.

session_id() should not be at risk of SQL injection since it is server side.  I have just escaped it anyways though.

I have also switched from mt_rand to openssl_random_pseudo_bytes.  Thanks to NLNico for the tip, I had not realized that mt_rand was insecure.
Also thanks to NLNico for pointing out the flaw in getinfo.php, which is now resolved.

Based on my research, PDO->quote is secure. There are only a couple of user-entered fields in the app and they are now being handled correctly to avoid CSRF.

NLNico, please PM me your BTC address to receive 0.1 BTC.

[Zoomer]

Would it not be a lot cheaper and maybe more safe if you try to hire a professional service for this?

I could be wrong but i think it's really the best and even quicker option since they also offer to fix the issues!

Because what if someone really find a big hole and he will keep it and not tell you, and then use it once there is a lot cash to steal?

Since this is already open source, I don't see any additional risk from asking people here to check for flaws.

If vulnerabilities are found, multiple people should find it; therefore each person has incentive to be the first to report & claim the bounty.

Sorry i missed the fact it's allready open source but i still belive that you are taking a huge risk like i said before, it's enough that someone hold a big exploit that other people maybe not found out and he will use it at the right moment

[BilalHIMITE]

session_id() should not be at risk of SQL injection since it is server side.  I have just escaped it anyways though.

The cookie value support all the alpanums +

Code:

!#$%&'()*+-./:<=>?@[]^_`{|}~

Putting a ' in the PHPSESSID value can be used to SQL Injection.

 

[NLNico]

session_id() should not be at risk of SQL injection since it is server side.  I have just escaped it anyways though.

The cookie value support all the alpanums +

Code:

!#$%&'()*+-./:<=>?@[]^_`{|}~

Putting a ' in the PHPSESSID value can be used to SQL Injection.

 

This is incorrect.

From the PHP documentation:

For example, the file session handler only allows characters in the range a-z A-Z 0-9 , (comma) and - (minus)!

You can also very easily test this yourself. Just echo both session_id() and $_COOKIE["PHPSESSID"]. You can see that the cookie value will be echo-ed even with ' or " in it, however the session_id will be empty. But if you change the cookie with only aZ09-, it will be also returned with the session_id function.

[minifrij]

I'm unsure if this has already been mentioned, but there is a small SQL error that I have found in api.php on your server.
When calling the API through a URL similar to /api/1, the SELECT query throws the error 'Unknown column 'num_voting_options' in 'field list'.'. After looking in your sql folder, I believe the problem is that you are trying to query the table games to get the num_voting_options and max_voting_fraction columns, when these columns are instead located in the event_types table.
In addition, when querying the games table in the same query, you seem to deal with the game_id as a string by encasing it in apostrophes. Considering that in schema_initial.sql game_id is initialized as an int(11), this isn't needed and could cause problems down the line. If you're worried about SQL injection being used when not encasing the game_id you could use the ctype_digit(); function in PHP to be sure. If not, I would really suggest using PDO->prepare as NLNico suggested; it is a lot safer in general than simply trying to escape the strings before querying.

[joey.rich]

Looks interesting Joey.Rich  
Will look into joining into it soon!

We need more testers, would love to have you in the game! Right now, we have a series of election-themed games running.  Each game lasts a day or less and simulates the 2016 US Presidential election, with elections being held in each of the 50 states every 20 minutes.

See EmpireCoin: Mock Election 2016 thread to start playing.

I'm unsure if this has already been mentioned, but there is a small SQL error that I have found in api.php on your server.
When calling the API through a URL similar to /api/1, the SELECT query throws the error 'Unknown column 'num_voting_options' in 'field list'.'. After looking in your sql folder, I believe the problem is that you are trying to query the table games to get the num_voting_options and max_voting_fraction columns, when these columns are instead located in the event_types table.
In addition, when querying the games table in the same query, you seem to deal with the game_id as a string by encasing it in apostrophes. Considering that in schema_initial.sql game_id is initialized as an int(11), this isn't needed and could cause problems down the line. If you're worried about SQL injection being used when not encasing the game_id you could use the ctype_digit(); function in PHP to be sure. If not, I would really suggest using PDO->prepare as NLNico suggested; it is a lot safer in general than simply trying to escape the strings before querying.

API functionality is not currently functional, since making some major changes recently.  I'll try to get it working soon though.  Will also be switching to prepared statements.

[Salmen]

I guess, you should validate the input datas such as subscribing for the newsletter.

Use the code:

Code:

if(filter_var($email, FILTER_VALIDATE_EMAIL)) { } 

[sazonk]

Hello dev..
what rule for join ths bounty ?
i wanna join for this campaign

[x4]

Hello dev..
what rule for join ths bounty ?
i wanna join for this campaign

What are talking about? Are you reading the OP?
First and foremost this is not a campaign like a signature campaign and this thread is only for some devs and bug hunter here in forum that loves for finding bugs and exploit to make money in some websites. So if you don't have this skill, then this thread is not for you. And if you want to join in signature campaigns, all you have to do first is make your post quality good so you can easily join in any campaigns that suits to your rank and as what I've see you already spamming the whole service section
And a little advice make sure you are already a member rank before joining in any campaigns so you easily make money and be careful you can be ban in this forum because of spamming.