Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
| Producto o servicio | Artículo |
|---|---|
| WCF |
|
| API Web | |
| Aplicación web |
|
WCF: no incluir el nodo serviceDebug en el archivo de configuración
| Título | Detalles |
|---|---|
| Componente | WCF |
| Fase de SDL | Construir |
| Tecnologías aplicables | Genérico, .NET Framework 3 |
| Atributos | N/A |
| References | MSDN, Fortify Kingdom |
| Pasos | Los servicios de Windows Communication Framework (WCF) pueden configurarse para exponer información de depuración. La información de depuración no debe usarse en entornos de producción. La etiqueta define si la característica de información de depuración está habilitada para un servicio WCF. Si el atributo includeExceptionDetailInFaults se establece en true, se devolverá información de excepción de la aplicación a los clientes. Los atacantes pueden aprovechar la información adicional que obtienen de la salida de depuración para montar ataques dirigidos al marco, la base de datos u otros recursos usados por la aplicación. |
Ejemplo
El siguiente archivo de configuración incluye la etiqueta :
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name=""MyServiceBehavior"">
<serviceDebug includeExceptionDetailInFaults=""True"" httpHelpPageEnabled=""True""/>
...
Deshabilite la información de depuración en el servicio. Esto se puede lograr quitando la etiqueta del archivo de configuración de la aplicación.
WCF: no incluir el nodo serviceMetadata en el archivo de configuración
| Título | Detalles |
|---|---|
| Componente | WCF |
| Fase de SDL | Construir |
| Tecnologías aplicables | Genérico |
| Atributos | Genérico, .NET Framework 3 |
| References | MSDN, Fortify Kingdom |
| Pasos | Exponer públicamente información sobre un servicio puede proporcionar a los atacantes información valiosa sobre cómo podrían aprovechar el servicio. La etiqueta habilita la característica de publicación de metadatos. Los metadatos del servicio pueden contener información confidencial que no debe ser accesible públicamente. Como mínimo, permita que los usuarios de confianza accedan a los metadatos y asegúrese de que no se expone información innecesaria. Mejor aún, deshabilite completamente la capacidad de publicar metadatos. Una configuración de WCF segura no contendrá la etiqueta . |
Asegúrese de que el control de excepciones adecuado se realiza en ASP.NET Web API
| Título | Detalles |
|---|---|
| Componente | API de la Web |
| Fase de SDL | Construir |
| Tecnologías aplicables | MVC 5, MVC 6 |
| Atributos | N/A |
| References | Exception Handling in ASP.NET Web API, Model Validation in ASP.NET Web API |
| Pasos | De forma predeterminada, la mayoría de las excepciones no detectadas en ASP.NET Web API se traducen en una respuesta HTTP con código de estado 500, Internal Server Error |
Ejemplo
Para controlar el código de estado devuelto por la API, puede usarse como se muestra a continuación:
public Product GetProduct(int id)
{
Product item = repository.Get(id);
if (item == null)
{
throw new HttpResponseException(HttpStatusCode.NotFound);
}
return item;
}
Ejemplo
Para controlar aún más la respuesta de la excepción, la clase se puede usar como se muestra a continuación:
public Product GetProduct(int id)
{
Product item = repository.Get(id);
if (item == null)
{
var resp = new HttpResponseMessage(HttpStatusCode.NotFound)
{
Content = new StringContent(string.Format("No product with ID = {0}", id)),
ReasonPhrase = "Product ID Not Found"
}
throw new HttpResponseException(resp);
}
return item;
}
Para detectar excepciones no controladas que no son del tipo , se pueden usar filtros de excepciones. Los filtros de excepciones implementan la interfaz . La manera más sencilla de escribir un filtro de excepción es derivar de la clase e invalidar el método OnException.
Ejemplo
Este es un filtro que convierte excepciones en código de estado HTTP :
namespace ProductStore.Filters
{
using System;
using System.Net;
using System.Net.Http;
using System.Web.Http.Filters;
public class NotImplExceptionFilterAttribute : ExceptionFilterAttribute
{
public override void OnException(HttpActionExecutedContext context)
{
if (context.Exception is NotImplementedException)
{
context.Response = new HttpResponseMessage(HttpStatusCode.NotImplemented);
}
}
}
}
Hay varias maneras de registrar un filtro de excepción de API web:
- Mediante acción
- Por controlador
- Globalmente
Ejemplo
Para aplicar el filtro a una acción específica, agregue el filtro como atributo a la acción:
public class ProductsController : ApiController
{
[NotImplExceptionFilter]
public Contact GetContact(int id)
{
throw new NotImplementedException("This method is not implemented");
}
}
Ejemplo
Para aplicar el filtro a todas las acciones de un , agregue el filtro como atributo a la clase :
[NotImplExceptionFilter]
public class ProductsController : ApiController
{
// ...
}
Ejemplo
Para aplicar el filtro globalmente a todos los controladores de API web, agregue una instancia del filtro a la colección. Los filtros de excepción de esta colección se aplican a cualquier acción del controlador de API web.
GlobalConfiguration.Configuration.Filters.Add(
new ProductStore.NotImplExceptionFilterAttribute());
Ejemplo
Para la validación del modelo, el estado del modelo se puede pasar al método CreateErrorResponse como se muestra a continuación:
public HttpResponseMessage PostProduct(Product item)
{
if (!ModelState.IsValid)
{
return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
}
// Implementation not shown...
}
Consulte los vínculos de la sección de referencias para obtener más detalles sobre el control excepcional y la validación de modelos en ASP.NET Web API
No exponer los detalles de seguridad en los mensajes de error
| Título | Detalles |
|---|---|
| Componente | Aplicación web |
| Fase de SDL | Construir |
| Tecnologías aplicables | Genérico |
| Atributos | N/A |
| References | N/A |
| Pasos | Los mensajes de error genéricos se proporcionan directamente al usuario sin incluir datos confidenciales de la aplicación. Entre los ejemplos de datos confidenciales se incluyen:
Capturar todos los errores dentro de una aplicación y proporcionar mensajes de error genéricos, así como habilitar errores personalizados en IIS ayudarán a evitar la divulgación de información. La base de datos de SQL Server y el control de excepciones de .NET, entre otras arquitecturas de control de errores, son especialmente detallados y muy útiles para la evaluación del perfil de una aplicación por parte de un usuario malintencionado. No muestre directamente el contenido de una clase derivada de la clase Exception de .NET y asegúrese de que tiene un control de excepciones adecuado para que una excepción inesperada no se genere accidentalmente directamente al usuario.
|
Implementación de la página de gestión de errores predeterminada
| Título | Detalles |
|---|---|
| Componente | Aplicación web |
| Fase de SDL | Construir |
| Tecnologías aplicables | Genérico |
| Atributos | N/A |
| References | Editar el cuadro de diálogo de configuración de páginas de error de ASP.NET |
| Pasos | Cuando se produce un error en una aplicación de ASP.NET y se produce un error de servidor interno HTTP/1.x 500, o una configuración de características (como filtrado de solicitudes) impide que se muestre una página, se generará un mensaje de error. Los administradores pueden elegir si la aplicación debe mostrar un mensaje descriptivo al cliente, un mensaje de error detallado al cliente o un mensaje de error detallado solo en localhost. La etiqueta del web.config tiene tres modos:
Abra el archivo de la aplicación o el sitio y asegúrese de que la etiqueta tiene definido o . |
Configurar el método de implementación a Comercial en IIS
| Título | Detalles |
|---|---|
| Componente | Aplicación web |
| Fase de SDL | Despliegue |
| Tecnologías aplicables | Genérico |
| Atributos | N/A |
| References | Elemento de implementación (esquema de configuración de ASP.NET) |
| Pasos | El conmutador está diseñado para su uso en servidores IIS de producción. El conmutador se utiliza para ayudar a que las aplicaciones funcionen con el mejor rendimiento posible y la menor pérdida posible de información de seguridad al deshabilitar la capacidad de la aplicación para generar salida de seguimiento en una página, deshabilitar la capacidad de mostrar mensajes detallados de error a los usuarios finales y deshabilitar el conmutador de depuración. A menudo, los conmutadores y opciones que están enfocadas hacia en el desarrollador, como los errores de solicitud de seguimiento y depuración, se habilitan durante el desarrollo activo. Se recomienda establecer el método de implementación en cualquier servidor de producción en modo retail. abra el archivo machine.config y asegúrese de que permanece establecido en true. |
Las excepciones deben fallar de manera segura
| Título | Detalles |
|---|---|
| Componente | Aplicación web |
| Fase de SDL | Construir |
| Tecnologías aplicables | Genérico |
| Atributos | N/A |
| References | Fail securely (Control seguro de los errores) |
| Pasos | La aplicación debe generar un error con seguridad. Cualquier método que devuelva un valor booleano, en función del cual se tome cierta decisión, debe tener un bloque de excepciones cuidadosamente creado. Hay muchos errores lógicos que provocan problemas de seguridad cuando el bloque de excepciones se escribe sin cuidado. |
Ejemplo
public static bool ValidateDomain(string pathToValidate, Uri currentUrl)
{
try
{
if (!string.IsNullOrWhiteSpace(pathToValidate))
{
var domain = RetrieveDomain(currentUrl);
var replyPath = new Uri(pathToValidate);
var replyDomain = RetrieveDomain(replyPath);
if (string.Compare(domain, replyDomain, StringComparison.OrdinalIgnoreCase) != 0)
{
//// Adding additional check to enable CMS urls if they are not hosted on same domain.
if (!string.IsNullOrWhiteSpace(Utilities.CmsBase))
{
var cmsDomain = RetrieveDomain(new Uri(Utilities.Base.Trim()));
if (string.Compare(cmDomain, replyDomain, StringComparison.OrdinalIgnoreCase) != 0)
{
return false;
}
else
{
return true;
}
}
return false;
}
}
return true;
}
catch (UriFormatException ex)
{
LogHelper.LogException("Utilities:ValidateDomain", ex);
return true;
}
}
El método anterior siempre devolverá True, si se produce alguna excepción. Si el usuario final proporciona una dirección URL con formato incorrecto, que el explorador respeta, pero el constructor no, se producirá una excepción y la víctima se llevará a la dirección URL válida pero con formato incorrecto.