La API de Oraclize permite a los usuarios cifrar una consulta o parte de una consulta usando su clave pública "para proteger los datos del escrutinio público", para citar su documentación.
La documentación dice lo siguiente sobre los ataques de reproducción: "Para evitar que otros usuarios utilicen su consulta cifrada exacta ('ataques de reproducción'), el primer contrato que consulta a Oraclize con una consulta cifrada dada se convierte en su 'propietario' legítimo. Cualquier otro contrato que use exactamente la misma cadena recibirá un resultado vacío".
Algunos puntos de aclaración:
Si envío una consulta de cálculo en la que un token de API cifrado es uno de los argumentos y los otros argumentos no están cifrados, ¿podrá un atacante usar mi token de API para realizar consultas de cálculo con diferentes argumentos de texto sin formato? La documentación se refiere a "esa misma cadena exacta", pero no me queda claro si se refiere a un solo argumento o a la consulta completa.
Si un atacante intenta un ataque de repetición utilizando "exactamente la misma cadena" y Oraclize devuelve un "resultado vacío" a ese usuario, ¿qué ha sucedido exactamente entre bastidores? ¿Oraclize realmente ejecutó la consulta y luego simplemente ocultó el resultado a la persona que llama? Si es así, eso es un problema, porque la mayoría de las API tienen un límite de solicitud, y un atacante podría usar esto para enviar spam a la API externa y exceder el límite de solicitud de token, rompiendo así el contrato inteligente. Mi API externa específica tiene un límite de 5 solicitudes por segundo y 1000 solicitudes por día, por lo que no es muy difícil abusar de esto, especialmente porque cada consulta de cálculo realizará varias solicitudes a la API externa.
¿La protección contra ataques de repetición se aplica a todas las redes o solo a la red principal? Es decir, ¿alguien puede tomar mi token de API encriptado de la red principal y usarlo en Rinkeby para enviar spam a la API externa y romper mi contrato inteligente? ¿O la característica de "propietario legítimo" es consistente en todas las redes?
Cualquier acción de "descifrado" pasará por las verificaciones del propietario, por lo que no importa si es la cadena completa la que está encriptada, una cadena parcial o un solo argumento, cualquier instancia vista, verifica la base de datos interna, para ver si se ha utilizado antes , y si es así, asegura que se origina en la dirección del contrato inicial. En resumen, a todo lo que use el descifrado de consultas de Oraclize se le asignará un propietario y se bloqueará para ese propietario.
Si Oraclize devuelve una cadena vacía, esto normalmente indica un error en algún lugar de la canalización, y la parte de la canalización estará antes de que se realice la solicitud real. El error específico para una reproducción normalmente será: datasources.decrypt.access_denied, que sería visible al verificar la consulta en el motor, o a través de la API HTTP, que se usa principalmente internamente. Consulta de ejemplo con un error (processor.query_error) https://api.oraclize.it/v1/query/eth_mainnet_684c58f66467b51e48a9559ee5becf6bd03ef2bc0028ee0fe584bd041a6a3641/status?_pretty=1 . Entonces, en resumen, no debe preocuparse por si se ha realizado una solicitud real, si hay una repetición, se detiene de forma preventiva en ese punto y la consulta se resuelve con un resultado vacío.
La protección de reproducción solo está 100% garantizada en la red principal. También es compatible con testnet, pero no hay garantías de que las bases de datos que les pertenecen no se eliminen, etc. Por lo tanto, en el contexto de testnet, recomendamos en su lugar usar claves de prueba/desarrollo, que si se comprometen o se reproducen no afectarían nada serio, ¡y solo cifrar las claves de producción para el uso de la red principal!
hoyo de jazz
DenisM
usuario2284570