He leído en todas partes que exponer personalsobre rpc es peligroso y vulnerable. La pregunta es: HOW?¿es posible que alguien envíe transacciones a mi consola geth, si mi ipaddresspuerto y el puerto en el que está escuchando geth están comprometidos?
En segundo lugar, no entiendo si es una amenaza a la seguridad, ¿cómo pueden algunas monedas basadas en Ethereum proporcionar su propia billetera? Deben estar usando RPC api para conectarse a geth. ¿No está en riesgo su moneda?
También estoy creando una interfaz web para mi moneda web3.jspara que los usuarios de mi moneda puedan usar la web para acceder a sus cuentas y realizar transacciones, pero para eso necesito exponer personalmás RPC. ¿Estoy comprometiendo la seguridad? En caso afirmativo, ¿qué más puedo hacer para proporcionar acceso web a mis usuarios de sus cuentas?
Pueden-rpcaddry -rpccorsdomainayudar de alguna manera? No pude entender su uso correctamente. Si configuro --rpcaddr "ip1", "ip2" --rpccorsdomain "ip1", ¿Qué significa esto?
Sobre las preguntas específicas de RPC:
--rpcaddres la dirección en la que el servidor geth rpc del usuario estaría escuchando. Por defecto es localhost. Localhost normalmente solo es accesible para un proceso que envía mensajes en la misma computadora, que normalmente es lo que desea. Si establece esto en una dirección IP pública, cualquiera puede conectarse a su nodo, lo cual es muy malo si el nodo controla su dinero y le ha dicho que permita que la gente lo gaste enviándole solicitudes a través de la red.
Si está aceptando solicitudes en localhost, cualquier proceso que se ejecute localmente puede conectarse a él. Sin embargo, sus usuarios confían en todos los procesos que se ejecutan en sus computadoras locales, ¿verdad? Bueno, tal vez no. El primer problema es que cualquier otra aplicación puede robar su dinero. Pero con suerte no descargaron ninguna aplicación sospechosa que intente hacer esto. Pero el segundo problema es que su navegador también ejecuta aplicaciones: no solo su aplicación, sino también el JavaScript de cualquier otro sitio que el usuario esté visitando.
Los navegadores intentan manejar esto con algo llamado Política del mismo origen. Esto significa que, de forma predeterminada, solo puede escribir JavaScript para acceder al mismo dominio y al mismo puerto que está utilizando para ver una página. Incluso esto es un poco asqueroso, porque hay muchas formas en que puede enviar datos desde los navegadores y no todos están bloqueados, y toda esta configuración tiene una superficie de ataque terriblemente grande. Pero la gente a veces quiere hacer excepciones a esta política, por lo que hay algo llamado Intercambio de recursos de origen cruzado (CORS), donde un navegador le preguntará a un servidor, "aparte de usted, ¿hay otros dominios y puertos que sirvan páginas web que quieres que te permita hablar contigo?".
Esto es lo que llama Geth --rpccorsdomain. Si desea que un navegador hable con geth y el navegador muestra una página de un servidor web en localhost, al menos debe especificar localhost más el puerto en el que se encuentra el servidor. Si desea ofrecer a las personas la aplicación de su dominio, deben decirle a su geth que permita que las páginas de su dominio gasten su dinero.
Todo esto es horrible. Qué asco. Además, argh.
Cualquiera que tenga la dirección IP del nodo y el puerto puede usar el proveedor de RPC; no hay autenticación. Es solo HTTP de texto sin formato. Ha habido al menos un ataque en el que un atacante obtuvo acceso a través de RPC a un nodo donde se desbloquearon las cuentas.
También existe el proveedor de IPC , que se basa puramente en el sistema de archivos. geth attach, por defecto, usa el IPC, y por defecto el IPC tiene acceso a cada API. Probablemente tendría mucho más éxito trabajando con IPC en lugar de intentar asegurar una conexión RPC. Mist usa IPC, por ejemplo.
Este tipo de escenarios, donde usa la interfaz web3 para interactuar con el nodo Geth, personalnunca se expone. Idealmente geth, solo expone las API de solo lectura para la interacción de JavaScript del lado del cliente que no es de confianza.
En lugar de esto, usa el nodo solo para transmitir la transacción a la red. No utiliza las API de RPC para crear transacciones ni interactuar con secretos (claves privadas).
Todos los secretos se almacenan en el lado del cliente ( window.localStorage) o los usuarios los copian y pegan (copiar y pegar la clave privada hexadecimal en el campo de entrada). Luego, web3 firma la transacción en el lado del cliente y solo envía transacciones completas a través de un nodo. Alternativa, para enviar transacciones, puede usar los servicios de transacciones push (ejemplo https://etherscan.io/pushTx )
RPC. Escribí una interfaz HTML web3que funciona bien. Pero tiene problemas de seguridad, como permitir que los usuarios realicen transacciones a través de eso http interface, tengo que permitir personalRPC, lo cual no se recomienda. Entonces, ¿qué más son mis opciones? Obviamente, otras monedas lo están haciendo, pero ¿CÓMO? ¿Lo estoy haciendo todo mal?Un truco simple podría ser alojar geth en un servidor separado y solo permitir rpc sobre localhost. Luego escriba una API simple en el servidor geth que recibirá solicitudes de su otro servidor, interactuará con geth y le enviará la respuesta. Puede proteger su API agregando una clave privada a las rutas para que nadie pueda visitar esas URL de API a menos que conozca la clave.
Aniket
Prashant Prabhakar Singh
web-walleta los usuarios de mi moneda.Muhammad Shahzad