@ OP, you may lock this thread since you have a replica of it at the service section where you are having a better response.

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

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.

So, the winning president is random then? How is it decided?

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.

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?

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).

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!

15YnqdubKqeq3v7RVaV38Qk7FrvLpvZ5vG

Sended a PM also.

How about I fix that error for you @OP ? I can give you a solution  to reject all the external access with the most "easiest" query out there ,like the one mentioned by KInzee.My pen testing tools are on the work!I should report you if I come across any more vulnerabilities!

EDIT : Does ddos attacks counts ?

Yes, he doesn't understand that.

I can send commands to the SQL, but I can't get data back.