Casi todos los ataques sobre los que he leído han implicado una mala codificación de sitios web de una forma u otra. Como ese ataque en el sitio de la billetera Doge en diciembre, donde supuestamente inyectaron el sitio web y entraron a través de una peculiaridad en Apache para modificar el código fuente, lo que permitió a los presuntos delincuentes modificar el destino de las transacciones reemplazando una variable. con una dirección codificada, que conducía a su billetera, robando así nuevas transacciones y retiros. Ha sido igual o similar con la mayoría de los otros ataques en sitios que almacenan billeteras en el servidor sobre el que he leído.
Por lo tanto, la importancia de codificar un sitio web seguro de varios niveles es muy importante. Necesito estar atento a los ataques de inyección, los problemas de permisos de apache y los puertos abiertos, y todas las cosas habituales que observaría en un sitio donde el dinero cambia de manos. Entiendo.
Pero, ¿es siempre la mala codificación del sitio web lo que hace que los propietarios de los sitios pierdan dinero? ¿Hay algo que un vándalo o un cracker potencial pueda hacer para comprometer mi sitio de otras formas? Además, ¿hay un documento técnico sobre la creación segura de sitios web potenciados por el protocolo bitcoin, en cualquier lugar?
Gracias de antemano por tu tiempo.
Debe asumir que su sitio va a ser pirateado y diseñarlo con eso en mente.
Echarle la culpa a la "mala codificación" es una forma de salir. Siempre habrá errores. Debe asegurarse de que sus procedimientos, sus protocolos, sean impecables a pesar de estos errores.
La mayoría de los bitcoins deben estar almacenados fuera de línea, y su billetera caliente debe estar en su propio servidor dedicado, con acceso a través de algún tipo de API muy limitada que realiza controles de cordura y limita la velocidad en todo. (El acceso podría ser a través de un daemon personalizado y escrito con mucho cuidado, es decir, ¡no solo una API HTTP de Apache con vulnerabilidades asociadas!)
Idealmente, el usuario posee una clave de cifrado que se utiliza para firmar transacciones del lado del cliente (o cualquier otra acción que realice) que se aplican a su cuenta o al monedero caliente.
Incluso entonces, un pirata informático podría secuestrar el servicio de sus páginas, modificar la criptografía, etc. para robar su clave. Pero al menos si la clave del usuario solo se generó una vez y solo la usa ocasionalmente, se reduce la posibilidad de robo masivo. La autenticación de dos factores también puede ayudar.
Podría tener demonios en otros servidores ocultos que verifiquen regularmente su sitio y sus recursos en busca de manipulación, suspendiendo todo si es necesario. Tal vez lance un complemento del navegador que verifique su sitio. Todo su sitio podría estar firmado y el complemento podría solicitar una nueva firma para verificar cualquier cambio. (Y realiza esta firma fuera de línea). Mientras el navegador del usuario o el sistema de publicación adicional no se vean comprometidos, todo irá bien ;)
Para resumir todo eso:
Hará todo esto y luego su proveedor de alojamiento se verá comprometido por la ingeniería social.
Al final del día, todo dicho y hecho, su protección más efectiva será la billetera fría fuera de línea con transferencias manuales (y lentas y molestas) de los fondos del cliente, y auditorías periódicas para verificar que todos los fondos estén realmente allí (mtgox lol).
por cierto, esto está escrito por alguien sin experiencia en seguridad, imagina lo que podría escribir alguien que sí tuviera esa experiencia;)
Punto final: si está pensando en ejecutar un servicio de billetera, no lo haga. Simplemente no lo hagas. Ríndete ahora. Va a terminar en lágrimas y amenazas de muerte.
Hay dos cosas que un hacker puede intentar para apoderarse de sus monedas: la vulnerabilidad en su código y la segunda es la fuerza bruta de su servidor para obtener acceso. En la mayoría de los casos, las vulnerabilidades de PHP se encuentran cuando afectan el sitio web porque cada programador piensa que su código es lo suficientemente seguro como para ser pirateado. Entre estos dos, PHP es más fácil de comprometer (no estoy diciendo que PHP no sea seguro). Le sugiero que le pida a la gente (si conoce a algún experto en seguridad o hacker) que penetre el código e intente encontrar una vulnerabilidad o puede comenzar una recompensa por eso.
Al diseñar un sistema de seguridad, primero debe decidir el nivel de seguridad necesario. ¿Qué nivel de seguridad estás buscando? ¿Cuántos $/moneda protegerá esto? ¿De qué ataques te estás protegiendo?
Hay dispositivos de gama alta que se autodestruyen al detectar una manipulación o un ataque utilizados por la industria bancaria y otros lugares donde las claves deben protegerse, si está creando un sitio a gran escala, definitivamente considere esa opción. Como ejemplo, Apple utiliza HSM (Módulos de seguridad de hardware) para proteger las claves de usuario de su servicio de mensajes.
Si le preocupa PHP o los lenguajes de secuencias de comandos en general, utilice un lenguaje compilado para la parte segura del sitio. Separe la parte segura de la parte del sitio que mira al usuario. Al segregar la parte de seguridad en una sección autónoma, la parte de seguridad real será más pequeña y, por lo tanto, más fácil de examinar. También reduzca la interfaz a la parte segura y valide todas las entradas. No desea que el código de seguridad se mezcle con todo el sitio.
Cuando diseñé productos de seguridad para el mercado masivo, pagué a un experto en seguridad de alto nivel para que revisara mi diseño e implementación. Sus primeras preguntas estaban en la línea de lo que pregunté anteriormente y más. El costo fue de alrededor de $ 2,000 / día.
Preste atención a la respuesta de @ user18443.
Yitzhak
Khan Shahrukh