Post216 nn

Hola hoy vengo a compartir un nuevo artículo, enfocado al mundo de desarrollo vinculado con seguridad, rails durante los últimos años se ha transformado en mi herramienta favorita de trabajo, ya sea por su rapidez al escribir código y lentitud al procesar datos XD. por otra parte la seguridad es algo muy importante al momento de desarrollar es por eso que hoy conoceremos los tips más importante de los cuales nos deberíamos de basar, cabe destacar que la seguridad va desde el inicio de desarrollo y no al final cuando ya lo terminamos:


Ejemplos Rails 3: 

1. CSRF match Routes

 

El CSRF (del inglés Cross-site request forgery o falsificación de petición en sitios cruzados) es un tipo de exploit malicioso de un sitio web en el que comandos no autorizados son transmitidos por un usuario en el cual el sitio web confía.

En el siguiente ejemplo para rails , en config/routes.rb

 

WebStore::Application.routes.draw do
  # Sample of named route:
  match 'products/:id/purchase' => 'catalog#purchase',
    :as => :purchase
  # This route can be invoked with
  # purchase_url(:id => product.id)
end

 

Esto tiene el efecto de enrutar la ruta / products /: id / purchase al método de compra CatalogController para todos los request HTTP (GET, POST, etc.). El problema es que la protección de falsificación de solicitudes entre sitios (CSRF) de Rails no se aplica a las solicitudes GET. Puede ver esto en el método para imponer la protección CSRF:

 

def verified_request?
  !protect_against_forgery? ||
  request.get? ||
  form_authenticity_token ==
    params[request_forgery_protection_token] ||
  form_authenticity_token ==
    request.headers['X-CSRF-Token']
end
 

 

La segunda línea realiza la comprobación de CSRF: significa que si request.get? es cierto, la solicitud se considera "verificada" y se omite la verificación CSRF. De hecho, en la fuente de Rails hay un comentario sobre este método que dice:

 

En su aplicación, siempre puede usar POST para realizar solicitudes a / products /: id / purchase. Pero como el enrutador también permite solicitudes GET, un atacante puede omitir de forma trivial la protección CSRF para cualquier método enrutado a través del ayudante #match. Si su aplicación utiliza la ruta de comodín anterior (no se recomienda), la protección CSRF es completamente inefectiva. Mejor práctica: No use GET para acciones inseguras. No uses #match para agregar rutas (en lugar de usar #post, #put, etc.). Asegúrate de no tener rutas comodín. La Solución: Rails ahora requiere que especifiques verbos HTTP específicos o mediante:: all al agregar rutas con #match. La configuración / route.rb generada ya no contiene rutas #match comentadas. (La ruta de comodín también se elimina.)

 

2.- Validación de atributos en el modelo:

 
Importante validar lo que estamos almacenando en nuestro motor:
 
validates_format_of :name, with: /^[a-z ]+$/i

 

Este código suele ser un error sutil. El desarrollador probablemente quiso hacer cumplir que el atributo de nombre completo está compuesto solo de letras y espacios. En su lugar, esto solo hará cumplir que al menos una línea en el nombre se compone de letras y espacios. Algunos ejemplos de coincidencia de expresiones regulares lo hacen más claro:

 
>> /^[a-z ]+$/i =~ "Joe User"
=> 0 # Match

>> /^[a-z ]+$/i =~ " '); -- foo"
=> nil # No match

>> /^[a-z ]+$/i =~ "a\n '); -- foo"
=> 0 # Match
 

El desarrollador debería haber usado los anclajes \ A (inicio de cadena) y \ z (final de cadena) en lugar de ^ (inicio de línea) y $ (final de línea). El código correcto sería:

 
validates_format_of :name, with: /\A[a-z ]+\z/i
 

Podría argumentar que el desarrollador tiene la culpa, y tendría razón. Sin embargo, el comportamiento de los anclajes de expresiones regulares no es necesariamente obvio, especialmente para los desarrolladores que no están considerando valores de varias líneas. (Quizás el atributo solo se expone en un campo de entrada de texto, nunca en un área de texto). Rails está en el lugar correcto de la pila para salvar a los desarrolladores de ellos mismos y eso es exactamente lo que se ha hecho en Rails 4. Práctica recomendada: siempre que sea posible, use \ A y \ z para anclar expresiones regulares en lugar de ^ y $. El Fix: Rails 4 introduce una opción multilínea para validates_format_of. Si su expresión regular está anclada utilizando ^ y $ en lugar de \ A y \ z y no pasa multilínea: verdadero, Rails generará una excepción. Este es un gran ejemplo de cómo crear un comportamiento predeterminado más seguro, al tiempo que proporciona control para anularlo cuando sea necesario.

 
 

3. Clickjacking

 

El secuestro de clics o los "ataques de reparación de la interfaz de usuario" implican representar el sitio de destino en un marco invisible y engañar a una víctima para que realice una acción inesperada cuando hace clic. Si un sitio es vulnerable al clickjacking, un atacante puede engañar a los usuarios para que realicen acciones no deseadas, como hacer una compra con un solo clic, seguir a alguien en Twitter o cambiar su configuración de privacidad. Para defenderse de los ataques de clickjacking, un sitio debe evitar que se renderice en un marco o iframe en sitios que no controla. Los navegadores más antiguos requerían feeds de Java "que rompen marcos", pero los navegadores modernos son compatibles con el encabezado HTTP de X-Frame-Options, que le indica al navegador si debe permitir el encuadre del sitio. Este encabezado es fácil de incluir y no es probable que rompa la mayoría de los sitios web, por lo que Rails debería incluirlo de manera predeterminada. Práctica recomendada: utilice RubyGem de Twitter de Secure_headers para agregar un encabezado de Opciones de X-Frame con el valor de SAMEORIGIN o DENY. La solución: De forma predeterminada, Rails 4 ahora envía el encabezado de Opciones de X-Frame con el valor de SAMEORIGIN:

 
X-Frame-Options: SAMEORIGIN

 

Esto le dice al navegador que su aplicación solo puede ser enmarcada por páginas que se originan en el mismo dominio.

 

4. User-Readable Sessions

El almacén de sesión de Rails 3 predeterminado utiliza cookies firmadas y sin cifrar. Si bien esto protege a la sesión de manipulación, es trivial para un atacante descifrar el contenido de una cookie de sesión:

 
session_cookie = <<-STR.strip.gsub(/\n/, '')
BAh7CEkiD3Nlc3Npb25faWQGOgZFRkkiJTkwYThmZmQ3Zm
dAY7AEZJIgtzZWtyaXQGO…--4c50026d340abf222…
STR

Marshal.load(Base64.decode64(session_cookie.split("--")[0]))
# => {
#   "session_id"  => "90a8f...",
#   "_csrf_token" => "iUoXA...",
#   "secret"      => "sekrit"
# }

 

No es seguro almacenar información confidencial en la sesión. Esperemos que esto sea bien conocido, pero incluso si la sesión de un usuario no contiene datos confidenciales, aún puede crear riesgos. Al decodificar los datos de la sesión, un atacante puede obtener información útil sobre los aspectos internos de la aplicación que se puede aprovechar en un ataque. Por ejemplo, puede ser posible entender qué sistema de autenticación está en uso (Authlogic, Devise, etc.). Si bien esto no crea una vulnerabilidad por sí solo, puede ayudar a los atacantes. Cualquier información sobre cómo funciona la aplicación se puede utilizar para perfeccionar las vulnerabilidades y, en algunos casos, para evitar la activación de excepciones o trucos que podrían dar al desarrollador una alerta temprana de que se está produciendo un ataque. Las sesiones legibles por el usuario violan el Principio de los privilegios mínimos, porque a pesar de que los datos de la sesión deben pasarse al navegador del visitante, no es necesario que el visitante pueda leer los datos. Práctica recomendada: no coloque ninguna información en la sesión a la que no quisiera que accediera un atacante. La solución: Rails 4 cambió el almacenamiento de sesión predeterminado para ser encriptado. Los usuarios ya no pueden descodificar el contenido de la sesión sin la clave de descifrado, que no está disponible en el lado del cliente. 



Artículos que te pueden interesar