Rook to XSS: Cómo hackeé chess.com con un exploit de novato
Un artículo sobre la explotación de la seguridad web de chess.com provoca tanto admiración por las sofisticadas técnicas de XSS y on-site request forgery del joven investigador como preocupación por cómo fallos sutiles de validación de entrada y de análisis de dominios pueden debilitar plataformas grandes. Los comentaristas comparan el caso con antiguos problemas de inyección HTML de la época de MySpace, profundizan en cómo fallan las comprobaciones ingenuas de same-origin y de URL, y señalan protecciones del navegador como las advertencias antiphishing de Chrome frente a subdominios engañosos. El hilo se amplía hacia visiones contrapuestas de chess.com con fines de lucro frente a lichess.org sin fines de lucro, la detección de trampas y cómo el trabajo de bug bounty puede moldear carreras tempranas, incluido el interés de grandes empleadores tecnológicos.
Complejidad del exploit y discusión técnica
- Muchos quedaron impresionados de que el exploit estuviera lejos de ser “de novato”: encadenaba múltiples debilidades, eludía validación, abusaba del editor de texto enriquecido y usaba subdominios y redirecciones cuidadosamente diseñados.
- Varios comentarios señalan lo difícil que es analizar dominios y sanear HTML, especialmente cuando se implementa con regex en lugar de parsers adecuados.
- El término “on-site request forgery (OSRF)” se aclara como análogo a CSRF pero dentro del mismo sitio.
- Las explicaciones del truco de subdominio enfatizan que la comprobación del lado del servidor de chess.com probablemente usaba coincidencia ingenua de cadenas en el hostname, no una verdadera comprobación de same-origin ni una allow-list adecuada.
- Algunos hablan de seguridad de cookies y XSS: la cookie principal de sesión era HttpOnly, pero otros datos sensibles eran accesibles en JavaScript; se aconseja confiar en bibliotecas de seguridad bien auditadas.
- Los editores de texto enriquecido se consideran “santos griales” para XSS y una fuente frecuente de errores sutiles.
Debate chess.com vs Lichess
- Muchos recomiendan Lichess, elogiándolo por ser gratis, de código abierto, sin fines de lucro, rápido y con potentes herramientas de análisis y un motor basado en WebAssembly en el navegador.
- Otros prefieren chess.com por la UX, la interfaz de análisis, los tutoriales y una detección de trampas y calidad de partidas percibidas como mejores.
- Las quejas sobre Lichess incluyen trampas muy extendidas, muchos rivales que abandonan las partidas y lecciones menos atractivas.
- Las críticas a chess.com se centran en funciones de análisis tras muro de pago, acuerdos de exclusividad con streamers y un comportamiento con fines de lucro compitiendo con una alternativa sin fines de lucro.
- Surge una tangente política/ideológica por la marca de Lichess, que se presenta humorísticamente con descriptores de inclinación izquierdista, provocando tanto críticas como apoyo.
Carrera y enfoque de bug bounty
- Los comentaristas quedan impresionados por la edad y la habilidad del autor, y sugieren un gran potencial profesional en seguridad.
- Se habla de referencias a grandes empresas tecnológicas, con desacuerdo sobre la ética de trabajar para ellas.
- Se discuten las apprenticeships de grado al estilo del Reino Unido como una fuerte alternativa a la universidad tradicional, especialmente en empresas conocidas.
Integridad del juego y detección de trampas
- Un usuario informa de un comportamiento extraño en chess.com (movimientos realizados por otros cuando no estaba conectado); otros se confunden y esto queda sin aclarar.
- Un subhilo explora la detección de trampas: el consenso es que comparar movimientos con recomendaciones del motor y usar análisis estadístico es lo central, con heurísticas de tiempo y consistencia como complementos.
- Anécdotas históricas recuerdan trucos de monitorización de clientes de la época temprana de la web, ahora en gran medida obsoletos.