Medidas adicionales de seguridad de aplicaciones

Además de las configuraciones de seguridad en HTTP, revisadas en el artículo “¿Por qué son tan importantes los header HTTP?” existen otros controles de seguridad en aplicaciones como configuraciones de red y servidores de aplicación, protección de APIs, uso de Content Delivery Networks (CDN), vigilancia de la cadena de suministro de software, deserialización segura, cumplimiento regulatorio en el manejo de datos, y pruebas periódicas de seguridad.

Con estas medidas adicionales de seguridad, también se busca cumplir con el control 8.25 de la ISO 27001:2022, que exige un ciclo de vida de desarrollo de software seguro (Secure SDLC).

Vulnerabilidades de red en aplicaciones web

No todas las vulnerabilidades en aplicaciones web están relacionadas con la forma en que funciona el protocolo HTTP. Las vulnerabilidades más importantes y no relacionadas con este protocolo son las siguientes, de acuerdo con el top 10 OWASP 2021.

• A02: Fallos Criptográficos.
• A04: Diseño Inseguro.
• A08: Fallos de integridad de software y datos.
• A09: Fallos de registro de logs y monitoreo de seguridad

Para reducir el impacto de estas vulnerabilidades no HTTP sobre una aplicación web, un desarrollador puede tomar las siguientes acciones.

Vulnerabilidades Top 10 OWASP 2021 que no necesariamente aprovechan HTTP

Las Conexiones HTTP cifradas (HTTPS) ya fueron revisadas en el primer artículo. El resto de acciones a ejecutar son acciones que únicamente tienen efecto sobre el lado del servidor en un modelo cliente - servidor.

Configuraciones de red para aplicaciones web

Un servidor puede ser On-premise, basado en nube o incluso un servicio (como AWS Amplify) combinado con funciones serverless (como AWS Lambda). En todos estos casos, el servidor en su forma más básica es un conjunto de recursos computacionales que permiten la ejecución del código de una aplicación web. Esos recursos se comunican entre ellos e interactúan con internet a través de una red. Las herramientas, a nivel de red, para proteger estos recursos, son las siguientes.

Virtual Private Clouds (VPCs): Redes aisladas virtualmente en la nube

En AWS, es posible usar diferentes framework para definir recursos como IaaC. En este caso, el framework serverless será elegido para definir, en infraestructura como código, una VPC como un recurso computacional. Esta VPC soporta direcciones IP dentro del rango 10.0.0.0/16 y tiene soporte DNS para resolver diferentes hosts y eventualmente permitir la salida a internet. El nombre de la VPC es “test_VPC” y estará desplegada en el entorno “Dev”:

resources:
  Resources:
    TestVPC:
      Type: AWS::EC2::VPC
      Properties:
        CidrBlock: 10.0.0.0/16
        EnableDnsHostnames: true
        EnableDnsSupport: true
        Tags:
          - Key: Name
            Value: test_VPC
          - Key: Environment
            Value: Dev

Subnets: Segmentos de red sobre una VPC

Una excelente práctica de seguridad es realizar segmentación de una red en función de los recursos que se utilicen y únicamente permitir comunicación entre los segmentos cuando sea necesario. Para este caso, crearemos segmentos de red dentro de esta VPC para servidores (servers), bases de datos (databases) y funciones lambda (lambda). En AWS las subnets pueden ser públicas (permiten acceso a internet) o privadas (no permiten acceso a internet). Todas las Subnets deben estar dentro del rango IP 10.0.0.0/16 ya definido como rango para toda la VPC. En este caso, las funciones lambda y las bases de datos no deberían tener posibilidad de conectarse a internet, entonces se usarán subnets privadas, mientras que los servidores deben exponerse a internet, entonces se dispondrá de una subnet pública.

En AWS existen diferentes availability zones (datacenter físicos) dentro de una región. Para reducir la latencia en la conexión de servicios, tanto el servidor, como la base de datos y las funciones lambda estarán dentro de la misma availability zone.

 Resources:
# Servers Subnet (Public)
    ServersSubnet:
      Type: AWS::EC2::Subnet
      Properties:
        VpcId:
          Ref: TestVPC
        AvailabilityZone: ${self:provider.region}a
        CidrBlock: 10.0.10.0/24
        MapPublicIpOnLaunch: true
        Tags:
          - Key: Name
            Value: test_VPC-servers-subnet
          - Key: Type
            Value: Public

    # Database Subnet (Private)
    DatabaseSubnet:
      Type: AWS::EC2::Subnet
      Properties:
        VpcId:
          Ref: TestVPC
        AvailabilityZone: ${self:provider.region}a
        CidrBlock: 10.0.20.0/24
        Tags:
          - Key: Name
            Value: test_VPC-database-subnet
          - Key: Type
            Value: Private

    # Lambda Subnet (Private)
    LambdaSubnet:
      Type: AWS::EC2::Subnet
      Properties:
        VpcId:
          Ref: TestVPC
        AvailabilityZone: ${self:provider.region}a
        CidrBlock: 10.0.30.0/24
        Tags:
          - Key: Name
            Value: test_VPC-lambda-subnet
          - Key: Type
            Value: Private

Access Control Lists (ACLs): Reglas de Firewall stateless virtuales aplicadas sobre una subnet

Las ACLs actúan como el primer control de seguridad para bloquear conexiones no requeridas. Se deben configurar conexiones tanto de entrada como de salida, ya que las ACLs son stateless. En este caso se debe considerar que incluso la conexión entre dos subnets que pertenecen a la misma VPC están limitadas por las reglas de las ACLs. A continuación, las subnets privadas únicamente permitirán conexiones de entrada y salida sobre los puertos de los protocolos HTTPs, SSH e ICMP, mientras que la subnet pública permitirá entrada y salida de datos en todos los puertos y protocolos. Para esta subnet pública, se aplicarán controles stateful más adelante, para evitar problemas en la conexión a la aplicación desde internet.

Resource: 
ServersNetworkAcl:
      Type: AWS::EC2::NetworkAcl
      Properties:
        VpcId:
          Ref: TestVPC
        Tags:
          - Key: Name
            Value: test_VPC-servers-nacl
          - Key: Environment
            Value: Dev

    ServersNetworkAclInboundHTTPS:
      Type: AWS::EC2::NetworkAclEntry
      Properties:
        NetworkAclId:
          Ref: ServersNetworkAcl
        RuleNumber: 110
        Protocol: 6
        RuleAction: allow
        CidrBlock: 0.0.0.0/0
        PortRange:
          From: 443
          To: 443

    ServersNetworkAclInboundSSH:
      Type: AWS::EC2::NetworkAclEntry
      Properties:
        NetworkAclId:
          Ref: ServersNetworkAcl
        RuleNumber: 120
        Protocol: 6
        RuleAction: allow
        CidrBlock: 0.0.0.0/0
        PortRange:
          From: 22
          To: 22


    ServersNetworkAclInboundICMP:
      Type: AWS::EC2::NetworkAclEntry
      Properties:
        NetworkAclId:
          Ref: ServersNetworkAcl
        RuleNumber: 140
        Protocol: 1
        RuleAction: allow
        CidrBlock: 0.0.0.0/0
        Icmp:
          Code: -1
          Type: -1

    ServersNetworkAclOutboundHTTPS:
      Type: AWS::EC2::NetworkAclEntry
      Properties:
        NetworkAclId:
          Ref: ServersNetworkAcl
        RuleNumber: 110
        Protocol: 6
        Egress: true
        RuleAction: allow
        CidrBlock: 0.0.0.0/0
        PortRange:
          From: 443
          To: 443

    ServersNetworkAclOutboundICMP:
      Type: AWS::EC2::NetworkAclEntry
      Properties:
        NetworkAclId:
          Ref: ServersNetworkAcl
        RuleNumber: 130
        Protocol: 1
        Egress: true
        RuleAction: allow
        CidrBlock: 0.0.0.0/0
        Icmp:
          Code: -1
          Type: -1

    # Private Network ACL (for Database and Lambda)
    PrivateNetworkAcl:
      Type: AWS::EC2::NetworkAcl
      Properties:
        VpcId:
          Ref: TestVPC
        Tags:
          - Key: Name
            Value: test_VPC-private-nacl
          - Key: Environment
            Value: ${self:provider.stage}

    # Private Network ACL Inbound Rules
    PrivateNetworkAclInboundVPC:
      Type: AWS::EC2::NetworkAclEntry
      Properties:
        NetworkAclId:
          Ref: PrivateNetworkAcl
        RuleNumber: 100
        Protocol: -1
        RuleAction: allow
        CidrBlock: 10.0.0.0/16

    # Private Network ACL Outbound Rules
    PrivateNetworkAclOutboundAll:
      Type: AWS::EC2::NetworkAclEntry
      Properties:
        NetworkAclId:
          Ref: PrivateNetworkAcl
        RuleNumber: 100
        Protocol: -1
        Egress: true
        RuleAction: allow
        CidrBlock: 0.0.0.0/0

    # Associate Servers Subnet with Servers NACL
    ServersSubnetNetworkAclAssociation:
      Type: AWS::EC2::SubnetNetworkAclAssociation
      Properties:
        SubnetId:
          Ref: ServersSubnet
        NetworkAclId:
          Ref: ServersNetworkAcl

    # Associate Database Subnet with Private NACL
    DatabaseSubnetNetworkAclAssociation:
      Type: AWS::EC2::SubnetNetworkAclAssociation
      Properties:
        SubnetId:
          Ref: DatabaseSubnet
        NetworkAclId:
          Ref: PrivateNetworkAcl

    # Associate Lambda Subnet with Private NACL
    LambdaSubnetNetworkAclAssociation:
      Type: AWS::EC2::SubnetNetworkAclAssociation
      Properties:
        SubnetId:
          Ref: LambdaSubnet
        NetworkAclId:
          Ref: PrivateNetworkAcl

ServersNetworkAclId:
      Description: ID of the servers network ACL
      Value:
        Ref: ServersNetworkAcl
      Export:
        Name: ${self:service}-Dev-ServersNetworkAclId

    PrivateNetworkAclId:
      Description: ID of the private network ACL
      Value:
        Ref: PrivateNetworkAcl
      Export:
        Name: ${self:service}-Dev-PrivateNetworkAclId

Security Groups (SG):

Un security group es un segundo control de seguridad para bloquear conexiones no requeridas que puede entenderse como reglas de firewall stateful aplicadas sobre una VPC. En el caso de servicios que pertenezcan a una VPC y deban ser expuestos a internet, es más conveniente usar un Security Group sobre una ACL para reducir la probabilidad de limitaciones en una conexión legítima.

TestSecurityGroup:
      Type: AWS::EC2::SecurityGroup
Resource:    
  Properties:
        GroupName: test_VPC-security-group
        GroupDescription: Security group for test_VPC
        VpcId:
          Ref: TestVPC
        SecurityGroupIngress:
          # Allow HTTPS access
          - IpProtocol: tcp
            FromPort: 443
            ToPort: 443
            CidrIp: 0.0.0.0/0
            Description: HTTPS access from anywhere
          # Allow all Internal VPC communication
          - IpProtocol: -1
            FromPort: -1
            ToPort: -1
            CidrIp: 10.0.0.0/16
            Description: All traffic within VPC
        SecurityGroupEgress:
          # Allow all outbound traffic
          - IpProtocol: -1
            FromPort: -1
            ToPort: -1
            CidrIp: 0.0.0.0/0
            Description: All outbound traffic
        Tags:
          - Key: Name
            Value: test_VPC-security-group
          - Key: Environment
            Value: Dev

NAT e Internet Gateways

Los NAT Gateways sirven para que un segmento de red privado pueda realizar conexiones de salida a internet (e.g. para obtener parches oficiales de un proveedor) a través de una IP pública (llamada Elastic IP Address o EIP en AWS). Estos segmentos de red privada se encuentran limitados para recibir conexiones desde el exterior incluso con una asignación de una EIP. En caso contrario, los Internet Gateways permiten tanto enviar como recibir conexiones desde y hacia internet. A continuación, la definición de ambos tipos de gateway para nuestra VPC.

Resource:

    # NAT Gateway EIP
    TestNATGatewayEIP:
      Type: AWS::EC2::EIP
      DependsOn: TestInternetGatewayAttachment
      Properties:
        Domain: vpc
        Tags:
          - Key: Name
            Value: test_VPC-nat-eip

    # NAT Gateway
    TestNATGateway:
      Type: AWS::EC2::NatGateway
      Properties:
        AllocationId:
          Fn::GetAtt:
            - TestNATGatewayEIP
            - AllocationId
        SubnetId:
          Ref: ServersSubnet
        Tags:
          - Key: Name
            Value: test_VPC-nat-gateway

    # Internet Gateway
    TestInternetGateway:
      Type: AWS::EC2::InternetGateway
      Properties:
        Tags:
          - Key: Name
            Value: test_VPC-igw

    # Attach Internet Gateway to VPC
    TestInternetGatewayAttachment:
      Type: AWS::EC2::VPCGatewayAttachment
      Properties:
        VpcId:
          Ref: TestVPC
        InternetGatewayId:
          Ref: TestInternetGateway

Configuraciones de servidor de aplicaciones

Un servidor de aplicaciones tradicional (como Nginx o Apache) o un servidor de aplicaciones como servicio (como AWS Amplify) requiere configuración más allá de las configuraciones de fábrica para exponerse de forma segura a internet. Es común que servidores de aplicaciones que funcionen bajo tecnologías obsoletas o vulnerables sean explotados en ciberataques.

• Deshabilitar módulos innecesarios en Nginx/Apache.
• TLS 1.3 obligatorio, desactivar versiones obsoletas.
• Automatizar actualizaciones con pipelines CI/CD.
• Escaneos de configuración con AWS Inspector o herramientas como Lynis.

AWS Amplify es un servicio gestionado para el despliegue de aplicaciones, lo que hace prescindible la existencia de una instancia EC2 ejecutando un servidor de aplicaciones.

Content Delivery Network (CDN)

Las fallas de disponibilidad de aplicaciones debido a ataques de denegación de servicio y ataques de denegación de servicio distribuidos son un problema serio para aplicaciones web que requieren alta disponibilidad. Existe una solución que además de proveer alta disponibilidad también proporciona cubrimiento global para aplicaciones que lo requieran y son las CDN. AWS Cloudfront es un CDN, que también ejecuta funciones básicas de WAF y balanceador de carga.

Cloudfront, al ser un servicio gestionado, puede proporcionar controles de seguridad más avanzados (por ejemplo, gestión de errores HTTP, reglas de filtrado HTTP básicas) que los que se pueden implementar con un balanceador de carga tradicional. Su configuración es de una complejidad similar a la de Amplify, por tanto no se profundizará en este artículo. Un ejemplo sobre cómo realizar en AWS puede ser consultado aquí.

Web Application Firewall

AWS WAF actúa como un firewall de aplicaciones web, cuya función principal es filtrar el tráfico HTTP malicioso antes de que pueda afectar una aplicación web. La arquitectura objetivo en AWS se vería potenciada en términos de seguridad al incorporar reglas gestionadas que detectan y bloquean ataques comunes como inyecciones SQL (SQLi) o cross-site scripting (XSS). La configuración de estas protecciones puede realizarse directamente desde la consola de AWS CloudFront, lo que facilita la gestión de recursos computacionales y permite a los desarrolladores web enfocarse en la evolución de la aplicación sin distraerse con los detalles de la administración de la seguridad de aplicaciones o seguridad en redes.

Conclusión

La seguridad de aplicaciones modernas no debe depender únicamente de seguridad en front end (e.g. HTTP headers). Un enfoque de defensa en profundidad exige asegurar:

• Red. (VPCs, SGs, ACLs).
• Servidor de aplicaciones. (hardening, TLS, actualizaciones).
• Disponibilidad de la aplicación y exposición a internet. (CDN y WAF).

Con estas medidas, los desarrolladores no solo cumplen con el control 8.25 de la norma ISO 27001:2022, sino que protegen sus aplicaciones frente a un entorno digital donde el malware como servicio, las amenazas persistentes avanzadas (APTs) y el vibe hacking usando modelos avanzados de IA pueden destruir la reputación de las compañías y la confianza en sus desarrolladores.