CSRF y XSRF significa "Cross-site request forgery". También es conocido como "uno de los ataques click / sesión de montar" y de corto plazo es CSRF / XSRF.
Entonces, ¿cómo funciona el ataque CSRF? Básicamente es cuando un atacante engañar a un usuario de confianza en el acceso a un sitio web o haciendo clic en una dirección URL que transmitir peticiones maliciosas sin el consentimiento del usuario a un sitio web de destino. He aquí un ejemplo simple: el uso de un par de trucos de ingeniería social, un atacante podría utilizar el software de chat QQ para encontrar una víctima y enviar un vínculo malicioso de la víctima específica para el sitio web del banco del usuario. Si la víctima se conecta a su cuenta de banca en línea y no sale, después, haga clic en un enlace enviado por el atacante, entonces los fondos de la cuenta bancaria del usuario podrían probablemente ser transferidos al atacante a la cuenta especificada.
Cuando se está bajo un ataque CSRF, el usuario final con una cuenta de administrador puede amenazar a toda la aplicación web.
El siguiente diagrama proporciona una visión simple de un ataque CSRF
Figure 9.1 CSRF attack process.
Como puede verse en la figura, para completar un ataque CSRF, la víctima debe completar estos dos pasos:
-1. Inicie sesión en sitios de confianza A, y almacenar una cookie local -2. Sin un sitio existente, el acceso a la peligrosa conexión al sitio B.
Vea aquí, el lector puede preguntarse: "Si no cumplo con las dos condiciones anteriores en cualquiera, no se hara el ataque CSRF." Sí, es cierto, pero no puede garantizar que el siguiente no sucede:
- Usted no puede garantizar que cuando se inicia la sesión en un sitio, el sitio no lauch los separadores ocultos.
- No se puede garantizar que, cuando se cierra el navegador, las cookies expiran inmediatamente y su última sesión ha terminado.
- A los sitios de alto tráfico de confianza no tiene vulnerabilidades ocultas que podría ser explotado con un ataque CSRF.
Por lo tanto, es difícil para un usuario a visitar una página web a través de un enlace y saber que no llevan a cabo operaciones de desconocidos para un ataque CSRF.
Ataques CSRF trabajan sobre todo a causa del proceso de autenticación Web. Aunque usted puede garantizar que una solicitud es desde el navegador de un usuario, no se puede garantizar que el usuario aprueba la solicitud.
Usted puede sentir un poco de miedo después de leer la sección anterior. Pero el terror es una buena cosa. Obligará a usted leer sobre cómo prevenir vulnerabilidades para que esto no le ocurra a usted.
Defensas contra CSRF se pueden construir en el servidor y en el cliente. Una defensa CSRF es más efectiva en el lado del servidor.
Hay muchas formas de prevenir ataques CSRF son el lado del servidor. La mayor parte de la madre de la defensiva de los dos aspectos siguientes:
- El mantenimiento de un uso adecuado GET, POST y Cookie.
- Incluya un número pseudo-aleatorio de las solicitudes no se obtiene.
En el capítulo anterior sobre REST, vimos cómo la mayoría de las aplicaciones web se basan en GET, peticiones POST, y que las cookies, donde se incluyen con la solicitud. Por lo general, el diseño de aplicaciones de la siguiente manera:
-
GET se utiliza comúnmente para visualizar la información sin el cambio de valores.
-
POST se utiliza en la colocación de órdenes, cambiar las propiedades de un recurso o realizar otras tareas.
Entonces voy a utilizar el lenguaje Go para ilustrar cómo restringir el acceso a los métodos de recursos:
mux.Get("/user/:uid", getuser)
mux.Post("/user/:uid", modifyuser)Después de este tratamiento, ya que se definen las modificaciones sólo pueden utilizar POST, GET método cuando se negó a responder a la solicitud, por lo que el método GET ilustración anterior de ataques CSRF se puede prevenir, pero todo se puede resolver el problema todavía? Por supuesto que no, porque el poste también puede simular.
Por lo tanto, tenemos que aplicar el segundo paso, la forma de las solicitudes de no llegar a aumentar el número aleatorio, esto probablemente tiene tres formas:
- Para cada usuario genera un testigo cookie única, todas las formas contienen el mismo valor pseudo-aleatorio, esta propuesta fue la más sencilla, ya que el atacante no puede obtener una cookie de terceros (en teoría), por lo que los datos en el formulario construirá fallar , pero es fácil porque la galleta XSS vulnerabilidad del usuario, ya que el sitio había sido robado, por lo que este programa debe ser en ausencia de circunstancias que de seguridad XSS.
- Cada solicitud para utilizar el código de verificación, este programa es perfecto, porque muchos entran el código de verificación, por lo que la facilidad de uso es pobre, no es adecuado para su uso práctico.
- Una forma diferente contiene un valor pseudo-aleatorio diferente, se introduce en la sección 4.4, "Cómo prevenir el envío de formularios múltiples" se introduce en este escenario, la reutilización de código relevante para lograr lo siguiente:
Generar una muestra de números aleatorios:
h := md5.New()
io.WriteString(h, strconv.FormatInt(crutime, 10))
io.WriteString(h, "ganraomaxxxxxxxxx")
token := fmt.Sprintf("%x", h.Sum(nil))
t, _ := template.ParseFiles("login.gtpl")
t.Execute(w, token)salida token:
<input type="hidden" name="token" value="{{.}}">Authenticacion token:
r.ParseForm()
token := r.Form.Get("token")
if token! = "" {
// Verification token of legitimacy
} Else {
// Error token does not exist
}Así que, básicamente, para lograr un POST seguro, pero tal vez usted podría decir si se rompe el algoritmo de identificador hace, de acuerdo con la teoría, pero, de hecho, el crack es básicamente imposible, porque alguien ha calculado la fuerza bruta de la cadena necesita cerca de 2 la 11 ª tiempo.
Cross-site request forgery, que CSRF, es un muy peligrosas amenazas a la seguridad web, es círculos de seguridad Web como "gigante dormido", el nivel de amenaza que la "reputación" se puede ver. Esta sección no sólo para cross-site request sí falsificación de una breve introducción, también detalla la razón que causa esta vulnerabilidad y poner un poco de orden para prevenir el ataque de sugerencias, con la esperanza de que el lector de escribir aplicaciones web seguras pueden inspirar.
- Directory
- Previous section: Security and encryption
- Next section: Filter inputs