Categories
.NET ASP.NET Miniposts Seguridad

Vulnerabilidades en .NET Framework

La boletín de seguridad de Microsoft para Julio, menciona tres problemas de seguridad en el .NET Framework, dos de éstos permiten la ejecución remota de código y el tercero permite descargar los contenidos de cualquier aplicación Web.

  • .NET PE Loader Vulnerability: A remote code execution vulnerability exists in .NET Framework that could allow an attacker who successfully exploited this vulnerability to make changes to the system with the permissions of the logged-on user. If a user is logged in with administrative user rights, an attacker could take complete control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
  • .NET JIT Compiler Vulnerability: A remote code execution vulnerability exists in .NET Framework Just In Time Compiler that could allow an attacker who successfully exploited this vulnerability to make changes to the system with the permissions of the logged-on user. If a user is logged on with administrative user rights, an attacker could take complete control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
  • ASP.NET Null Byte Termination Vulnerability: An information disclosure vulnerability exists in .NET Framework that could allow an attacker who successfully exploited this vulnerability to bypass the security features of an ASP.NET Web site to download the contents of any Web page.
Categories
ASP.NET Miniposts NHibernate Windows Forms

Videos sobre .NET

Presentaciones sobre .NET:

Categories
ASP.NET Seguridad

Eliminar la cabecera X-AspNet-Version

Gracias a Mads Kristensen, me entero de una forma sencilla de eliminar la cabecera X-AspNet-Version que normalmente se envía al cliente.

code:

HTTP/1.1 200 OK
Date: Mon, 02 Jul 2007 23:02:51 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET

X-AspNet-Version: 2.0.50727

Set-Cookie: ASP.NET_SessionId=f31vuhudwugmjje511e3szuy; path=/; HttpOnly
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 7391

Para evitar este comportamiento, hay que poner en false el valor del atributo enableVersionHeader del elemento httpRuntime:

xml:

<?xml version="1.0"?>
<configuration>
    <system.web>
      <httpRuntime enableVersionHeader="false"/>
    </system.web>
</configuration>

No entiendo el motivo de que enableVersionHeader esté habilitado por omisión, sabiendo que es mejor ocultar las versiones del software que se usa.

Categories
.NET Miniposts

Lecturas recomendadas sobre .NET

Algunos enlaces con información variada sobre .NET:

Categories
.NET

Tip: Detectar el estado de la red con .NET

Una forma sencilla de detectar el estado de las interfaces de red:

csharp:

using System;
using System.Net.NetworkInformation;

namespace Examples.Net.AddressChanges
{
    public class NetworkingExample
    {
        public static void Main()
        {
            NetworkChange.NetworkAddressChanged += new
                NetworkAddressChangedEventHandler(AddressChangedCallback);
            NetworkChange.NetworkAvailabilityChanged += new
                NetworkAvailabilityChangedEventHandler(NetworkChange_NetworkAvailabilityChanged);
            Console.ReadLine();
        }

        static void NetworkChange_NetworkAvailabilityChanged(object sender, NetworkAvailabilityEventArgs e)
        {
            Console.WriteLine(e.IsAvailable);
        }
        static void AddressChangedCallback(object sender, EventArgs e)
        {
            NetworkInterface[] adapters = NetworkInterface.GetAllNetworkInterfaces();
            foreach (NetworkInterface adapter in adapters)
            {
                Console.WriteLine("   {0} is {1}", adapter.Name, adapter.OperationalStatus);
            }
        }
    }
}

Tomé el ejemplo de la documentación por si algún día necesito hacer algo parecido. 😀