Topic: EmpireCoin: Bug bounty program (Read 1543 times)

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.

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

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

Use the code:

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.


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.

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.

This is incorrect.

From the PHP documentation:

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.

The cookie value support all the alpanums + Putting a ' in the PHPSESSID value can be used to SQL Injection.

 

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

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.

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.

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.



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.

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

I guess you really don't care about the SQL injection vector that's still up. Or you think I'm joking. Suit yourself.

You can use Cloudflare for DDOS protection, SSL (HTTPS), and Powerful stats about your visitors. Starting from $0.

I will still keep the client side hashing but then hash & salt on server side.


As we saw in the Heartbleed bug, encrypting with HTTPS is not necessarily secure; better to hash passwords on the client side first.

My webhost does provide some DDOS protection, I'm not sure how much though.  To handle DOS, this will soon be a P2P web app with many nodes.

Wireshark won't detect the passwords if it is converted to hashes after the onsubmit event.Though there is no need to use HTTPS for that specific purpose,you can use it for 100 other reasons anyway.On a side note,do implement DDos preventing mechanisms.What's the point of making your website 100% accurate when it just won't take the load of the bots ? Trust me,Ddos is one of the most often and primary attacks to take down your site!

I highly recommend you to use secure connection (HTTPS) on your website in case you're planning to implement server side hashing.
Because password will be sent in plain text, and can easily be detected by network protocol analyzers (e.g. wireshark).

Thanks joey.rich.
Looking for more vulnerabilities.

I have sent the 0.1 BTC, nice job finding this.

Thanks for the suggestion, I will implement salt & server side hashing soon.

You are welcome to submit a PR if you'd like but I'm not willing to put a bounty for that change.

DDOS is not eligible as it is not a vulnerability within the empirecoin-web source code.