Seguridad en ASP.NET
Según el proyecto OWASP estas son la mayoría de amenazas que
existen en una web basada en ASP.NET:
A1 – Injection
Lo que se acostumbra a ver son ataques de Inyección SQL o
SQLi donde se emplean consultan no deseadas para sobrecargar la aplicación.
Con este tipo de ataques se puede obtener toda la
información ya sea a nivel de servidor SQL como por ejemplo otras bases de
datos que alberguen en ese servidor y también, información del sistema
operativo donde corre tal servidor.
A2 – Broken
Authentication and Session Management
Se basa en la intercepción de la sesiones o cookies de la
web permitiendo acceder a una cuenta privada sin tener que loguearse mediante
contraseña en la web.
A3 – Cross-Site
Scriting (XSS)
Se basa en ejecutar código malintencionado dentro de
etiquetas HTML como:
<script>
<img src=”url archivo interno”>
<iframe>
Etc…
A5 – Insecure
Misconfiguration
Es la manipulación de variables globales como por ejemplo
manipular variables de javascript.
Modelo de
amenazas según Microsoft
Suplantación
(Spoofing)
Consistiría en introducir las credenciales de un usuario
diferente. Un usuario malintencionado podría también cambiar el contenido de
una cookie para fingir que es otra persona o que la cookie proviene de un
servidor diferente.
Se puede evitar con:
- Autenticación estricta
- Utilizando solamente un parámetro encriptado con Salt
o
Parámetros
cookie:
[“logon”] =
?id=user1&token=kehf8972th23toih&logonDateTime=20160727092018
o
Parámetros
cookie (Base64 sin Salt):
[“logon”] = ?xData= aWQ9dXNlcjEmdG9rZW49a2VoZjg5NzJ0aDIzdG9paCZsb2dvbkRhdGVUaW1lPTIwMTYwNzI3MDkyMDE4
Manipulación
(Deface):
Se basa en cambiar o eliminar un recurso sin autorización.
Se puede conseguir hacer un deface mediante técnicas de XSS
donde el usuario consigue ejecutar código enmascarado como parte de una entrada
de datos.
Repudio
Es la suplantación de un usuario usando sus credenciales. Se
deben utilizar funciones de auditoria de inicio sesión para identificar la
amenaza existente.
Revelación de
información
Es el hecho de desvelar información confidencial. Puede ser
voluntariamente (desconocimiento de que se está revelando) o involuntariamente
(robo).
Se debe revelar solo información necesaria o mínima.
Utilizar SSL siempre, si esta para su utilización sin SSL
debería redirigirla a la página bajo SSL.
Denegación del
servicio
Se basa en sobrecargar la disponibilidad del sistema.
Ejemplo:
En una conversación donde hablan todos hacia ti, llega un
momento que existe una saturación en el canal auditivo y tu cerebro no asimila
toda la información por este motivo te estas colapsando o bloqueando y llega un
momento que dejas de escuchar, para un sistema se le llama denegar el servicio.
Concesión de
privilegio
Un ataque de concesión de privilegio o elevación de
privilegios consiste en emplear cualquier medio disponible para obtener más
permisos de los asignados por la aplicación web.
Se recomienda ejecutar la aplicación con los permisos
mínimos, si resulta factible.
¿Cómo
protegernos frente amenazas SQL Injection?
- Utilizar permisos mínimos de base de datos (Lectura y/o Escritura)
- Validar las entradas de texto
- Utilizar LINQ
- Utilizar Stored Procedures
- Utilizar SQL Query Parametrization
¿Cómo
protegernos frente amenazas XSS?
-
Validar las entradas de texto ya sea URL’s o
inputs de los formularios para la validación se recomienda utilizar Regex.
¿Cómo
protegernos frente amenazas CSRF?
-
Utilizando AntiForgeryToken Helpers
-
Ejemplo:
En la View:
<%
using(Html.Form("UserProfile", "SubmitUpdate")) { %>
<%= Html.AntiForgeryToken() %>
<!-- rest of form goes here -->
<% } %>
En el Controller:
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc
}
Esto es por defecto pero se
recomienda utilizar Salt:
Ejemplo:
En la View:
<%=
Html.AntiForgeryToken("someArbitraryString") %>
En el Controller:
[ValidateAntiForgeryToken(Salt="someArbitraryString")]
public ViewResult SubmitUpdate()
{
// ... etc
}
Limitaciones de Anti-Forgery
-
Todos los clientes deberían aceptar cookies
-
Solo funciona con solicitudes POST y no con
solicitudes GET.
-
No se debe tener agujeros XSS debido a que sería
fácil hacer un bypass en alguno de sus agujeros o vulnerabilidad.
Más información: https://msdn.microsoft.com/en-us/library/ff649310.aspx
¿Cómo
protegernos frente amenazas a Denegaciones del servicio (DOS)?
-
En el caso de que haya recursos del sistema o
acceso a bases de datos, utilizar Try/Catch para liberar los recursos en el
caso de que se produzca un error.
-
Configurar la limitación de uso de CPU y Memoria
RAM en el servidor IIS
Vulnerabilidades
en el Web.config
-
CustomErrors:
o
No se debería mostrar los mensajes de error no
controlados simplemente porque el hacker lo utilizaría para poder obtener
información sobre que puede hacer y lo que no, es decir, los mensajes dan
pistas y según que pistas se puede deducir la técnica de hacking que se puede
utilizar.
o
Se aconseja almacenar los errores no controlados
en un log ya que pueden ser vulnerabilidades que haya encontrado el hacker.
o
En el Web.config de nuestra aplicación se
debería establecer en el customErrors lo siguiente:
<configuration>
<system.web>
<customErrors
mode="RemoteOnly" defaultRedirect="~/Default.aspx">
-
Trace:
o
localOnly debería estar a true
<configuration>
<system.web>
<trace
enabled="false" localOnly="true">
-
Debug:
o
Se debería establecer el atributo debug a false
en compilation
<configuration>
<system.web>
<compilation
debug="false">
-
Cookies:
o
Se debería establecer en el elemento
httpCookies, el atributo httpOnlyCookies a true
<configuration>
<system.web>
<httpCookies
httpOnlyCookies="true">
-
Cookieless:
o
Se debería establecer en el atributo cookieless
del elemento forms a UseCookies
<configuration>
<system.web>
<sessionState
cookieless="UseCookies">
-
SSL:
o
Si se posee un certificado SSL es aconsejable
establecer el atributo requireSSL a true, no permitir que se conecten sin SSL.
Cookies
seguras
- Establecer las propiedades Secure a True pero requiere SSL,
HttpOnly a True
- Cifrar toda la información dentro de las cookies
- No almacenar información sensible
- Se recomienda establecer fecha de expiración de
la cookie
Verbos de
peticiones HTTP
Tipos de verbos HTTP (según el
RFC2616)
GET: obtiene el recurso especificado
por la URL. La URL contiene toda la información necesaria para localizar y
obtener el recurso.
POST: envía o somete datos para que
sean procesados por el recurso identificado en la URL. Generalmente los datos
que se envían se especifican en el cuerpo de la petición. El ejemplo más
habitual es cuando subimos una imagen a un servidor a través del navegador ya
que el verbo empleado es POST y los
datos binarios de la imagen se especifican en el cuerpo de la petición.
PUT: sube o actualiza un recurso
especificado. Es la forma más eficiente de subir archivos a un servidor, pero
está en desuso porque la mayoría de las empresas de hosting tienen
deshabilitado este verbo, por eso se ha generalizado el uso del verbo
POST a la hora de subir archivos.
DELETE: Borra el recurso especificado.
HEAD: Obtiene sólo las cabeceras de una
petición. Es un verbo similar a GET,
sólo que GET además de las cabeceras
también obtiene el cuerpo de la respuesta.
TRACE: este método se emplea con fines
de diagnóstico ya que solicita al servidor que envíe todos los datos de la
solicitud enviada.
OPTIONS: sirve para obtener una lista
de los métodos HTTP que soporta el servidor (dicho de otra manera, nos informa
sobre los verbos que soporta el servidor).
CONNECT: se utiliza para saber si
tenemos acceso a un determinado host.
Se recomienda utilizar GET y POST, solamente.
Tipos de códigos de estado de una
respuesta HTTP (según el RFC2616)
·
1xx: Mensajes de información.
o 100
– 101 Conexión rechazada.
·
2xx: Mensajes de operación exitosa.
o 200
OK
o 201-203
Información no oficial
o 204
Sin Contenido
o 205
Contenido para recargar
o 206
Contenido parcial
·
3xx: Código de redirección.
o 301
Mudado permanentemente
o 302
Encontrado
o 303
Vea otros
o 304
No modificado
o 305
Utilice un proxy
o 307
Redirección temporal
·
4xx: Error por parte del cliente.
o 400
Solicitud incorrecta
o 401
No autorizado
o 402
Pago requerido
o 403
Prohibido
o 404
No encontrado
o 409
Conflicto
o 410
Ya no disponible
o 412
Falló precondición
·
5xx: Error del servidor.
o 500
Error interno
o 501
No implementado
o 502
Pasarela incorrecta
o 503
Servicio no disponible
o 504
Tiempo de espera de la pasarela agotado
o 505
Versión de HTTP no soportada
Muy buen articulo
ResponderEliminarGracias! Alberto!
Eliminar