Exemplo:
1 Alguem abre uma conta na exchange (possivelmente documentos falsos)
2 Transfere 1 BTC por exemplo pra lá
3 Ganha acesso ao webserver
4 Altera o book order direto no banco retirando todas as ordens de venda e todas de compra e faz as seguintes operacoes:
5 Cadastra uma ordem de venda igual ao valor total de todo o dinheiro disponivel nas contas de cada um
6 Cadastra ordens de compra pra gastar o dinheiro de todo mundo comprando aquele 1 BTC
7 Cadastra uma ordem de compra usando o dinheiro todo e valor do BTC a R$ 0.00000001
8 Cadastra ordens de venda de todos os BTCs em saldo
9 Pede uma retirada do saldo total da conta...
Como para o CronServer todas essas são operações 'validas' de compra e venda (saldo total de R$ e BTC está valido) ele vai processar as ordens todas e liberar os BTCs...
Você descreveu um ótimo exemplo de ataque que poderia ser implementado com um SQL Injection bem elaborado.
Mas acredito que na minha arquitetura ele seria barrado no CronServer já na etapa 4 (pois suas operações de exclusão de ordens não estariam conectadas a um token valido de login, necessário para cada usuario alterar as proprias ordens) - O Token de login registrado junto com as operações não foi mencionado na ilustração mas é um padrão minimo de segurança que deveria ser adotado juntamente com o restante.
Caso o invasor altere as ordens diretamente no BD do webserver, ou ainda tente registrar novas ordens (etapa 5,6,7,8), o BD se tornaria diferente da copia incremental presente no cronserver e o sistema inteiro se desativa, acionando o alarme de invasão.
Mas caso o invasor consiga forjar tokens de login, e consiga registrar exclusão de ordens e adicionar novas ordens, então ele ainda seria barrado na etapa 6, pois o mesmo BTC não poderia ser vendido mais de uma vez, pois a auditoria automatica é executada antes de cada ordem, e cuidaria disso, impedindo o ataque e bloqueando a conta.
Mas caso tudo dê errado e o atacante seja ninja o bastante para chegar na etapa 9, ele ainda assim seria barrado alí, pois o saldo é calculado usando todo o historico de depositos, saques e operações no mural, da exchange toda, usando checkpoints para diminuir o processamento. O saldo não fica registrado para uso em operações. Existe um saldo usado para exibição no webserver, mas mesmo assim é assinado para evitar que seja forjado.
Como a auditoria leva em conta o histórico inteiro da exchange desde o ultimo checkpoint, eu acho muito improvável que um saldo incorreto passe daqui.
Podem entender essa auditoria como um balanço de estoque que ordena tudo que entra e sai de cada conta, e no final os números precisam fechar com precisão.
E se ainda assim o cara seja um Hacker Ninja Super Sayajin e consiga burlar esse sistema inteiro, ele ainda esbarraria nos limites de saques automaticos, que fracionam os grandes valores em saques menores transferidos em períodos espaçados de tempo, e que não deixariam ele sacar muita coisa, e claro poderiam disparar um aviso ao admin que poderia ao menos estranhar um saque muito fora do comum e agir a tempo.
Eu não conseguiria invadir o meu sistema, mesmo conhecendo ele em detalhes mínimos.
Mas sei que sou só um aprendiz e possivelmente tem gente que daria conta disso com um pé nas costas.
Alguma ideia de como quebrar esses sistema ?