Почти каждая атака, о которой я когда-либо читал, так или иначе связана с плохим кодированием веб-сайта. Например, атака на сайт кошелька Doge в декабре, где они якобы внедрили веб-сайт и проникли через причуду Apache, чтобы изменить исходный код, что позволило предполагаемым мошенникам якобы изменить назначение транзакций, заменив переменную. с жестко закодированным адресом, который вел к их кошельку, тем самым крадя новые транзакции и снятие средств. То же самое или похоже на большинство других атак на сайты, хранящие кошельки на сервере, о которых я читал.
Поэтому важность кодирования безопасного многоуровневого веб-сайта очень важна. Мне нужно следить за инъекционными атаками, проблемами с разрешениями apache, открытыми портами и всеми обычными вещами, которые я бы наблюдал на сайте, где деньги переходят из рук в руки. Понятно.
Но всегда ли плохое кодирование веб-сайтов приводит к тому, что владельцы сайтов теряют деньги? Может ли потенциальный вандал или взломщик сделать что-нибудь, чтобы скомпрометировать мой сайт другими способами? Кроме того, есть ли где-либо технический документ по безопасному созданию веб-сайтов с поддержкой протокола биткойн?
Спасибо заранее за ваше время.
Вы должны предполагать, что ваш сайт будет взломан, и проектировать с учетом этого.
Обвинять вещи в «плохом кодировании» — это выход. Всегда будут ошибки. Вы должны быть уверены, что ваши процедуры, ваши протоколы безупречны, несмотря на эти ошибки.
Большинство биткойнов должно находиться в автономном хранилище, а ваш горячий кошелек должен находиться на собственном выделенном сервере с доступом через какой-то очень ограниченный API, который проверяет работоспособность и ограничивает скорость для всего. (Доступ может осуществляться через специальный и очень тщательно написанный демон, т. е. не просто какой-нибудь Apache HTTP API с соответствующими уязвимостями!)
В идеале пользователь владеет ключом шифрования, который используется для подписи транзакций на стороне клиента (или любых других действий, которые они предпринимают), которые применяются к его учетной записи или горячему кошельку.
Даже в этом случае хакер, предположительно, может захватить обслуживание ваших страниц, изменить криптографию и т. д., чтобы украсть их ключ. Но, по крайней мере, если ключ пользователя был сгенерирован только один раз и используется им только время от времени, вероятность массовой кражи снижается. Двухфакторная аутентификация тоже может помочь.
У вас могут быть демоны на других скрытых серверах, которые регулярно проверяют ваш сайт и его ресурсы на предмет несанкционированного доступа, приостанавливая все в случае необходимости. Возможно, выпустите надстройку для браузера, которая проверяет ваш сайт. Весь ваш сайт может быть подписан, и надстройка может запросить новую подпись для проверки любых изменений. (И вы выполняете это подписание в автономном режиме). Пока браузер пользователя или система публикации дополнений не будут скомпрометированы, все будет в порядке ;)
Подводя итог всему этому:
Вы сделаете все это, а затем ваш хостинг-провайдер будет скомпрометирован с помощью социальной инженерии.
В конце концов, все сказано и сделано, вашей наиболее эффективной защитой будет автономный холодный кошелек с ручным (и медленным и раздражающим) переводом средств клиента и регулярными проверками для проверки того, что все средства действительно там (mtgox, лол).
Кстати, это написано кем-то без опыта работы в сфере безопасности, представьте, что мог бы написать тот, у кого был такой опыт ;)
Заключительный момент: если вы думаете о запуске службы кошелька, не делайте этого. Просто не надо. Сдавайся сейчас. Это закончится слезами и угрозами смерти.
Есть две вещи, которые хакер может попытаться завладеть вашими монетами: во-первых, это уязвимость в вашем коде, а во-вторых, взломать ваш сервер, чтобы получить доступ. В большинстве случаев уязвимости PHP обнаруживаются, когда они оказывают влияние на веб-сайт, потому что каждый программист считает, что его код достаточно безопасен для взлома. Среди этих двух PHP легче скомпрометировать (я не говорю, что PHP небезопасен). Я предлагаю вам попросить людей (если вы знаете какого-либо эксперта по безопасности или хакера) проникнуть в код и попытаться найти уязвимость, или вы можете начать вознаграждение за это.
При проектировании системы безопасности в первую очередь необходимо определить необходимый уровень безопасности. Какой уровень безопасности вам нужен? Сколько $/coin это защитит? От каких атак вы защищаете?
Существуют высококачественные устройства, которые самоуничтожаются при обнаружении несанкционированного доступа или атаки, используемые в банковской сфере, и другие места, где ключи должны быть защищены, если вы создаете крупномасштабный сайт, обязательно рассмотрите этот вариант. Например, Apple использует HSM (аппаратные модули безопасности) для защиты своих пользовательских ключей службы сообщений.
Если вас беспокоит PHP или языки сценариев в целом, используйте скомпилированный язык для безопасной части сайта. Отделите безопасную часть от пользовательской части сайта. При отделении части безопасности в автономную часть фактическая часть безопасности будет меньше и, следовательно, ее будет легче проверить. Также уменьшите интерфейс до безопасной части и проверьте все входные данные. Вы не хотите, чтобы код безопасности смешивался со всем сайтом.
Когда я разрабатывал продукты безопасности для массового рынка, я заплатил эксперту по безопасности высшего уровня, чтобы он проверил мой дизайн и реализацию. Его первые вопросы были похожи на то, что я задавал выше, и многое другое. Стоимость составляла около 2000 долларов в день.
Обратите внимание на ответ @user18443.
Ицхак
Хан Шахрукх