Para el avance del Conocimiento y la Educación, y la Ciencia y la Tecnología en general, siempre ha sido de suma importancia la implementación de las mejores y más efectivas acciones, medidas o recomendaciones (Buenas Prácticas) para lograr el fin último de, realizar a buen término cualquier actividad o proceso.
Y la Programación o el Desarrollo del Software como cualquier otra actividad profesional y TI, tiene sus propias «Buenas Prácticas» asociadas a muchas esferas, sobre todo lo relacionado con la Ciberseguridad de los productos de software elaborados.
Y en esta publicación presentaremos algunas «Buenas Prácticas de Codificación Segura», de parte una interesante y útil web llamada «Secure Code Wiki», tanto sobre Plataformas de Desarrollo libres y abiertas, como privativas y cerradas.
Licencias para el desarrollo del Software Libre y Abierto: Buenas prácticas
Antes de adentrarnos en el tema, como de costumbre, dejaremos más adelante algunos enlaces de anteriores publicaciones relacionadas con el tema de las «Buenas Prácticas en Programación o Desarrollo del Software».
“… Buenas prácticas concebidas y divulgadas por la “Iniciativa Código para el Desarrollo” del Banco Interamericano de Desarrollo, sobre el ámbito de Licenciar Software, que debe llevarse a la hora de desarrollar productos de software (herramientas digitales), sobre todo libres y abiertos.”
Articulo relacionado: Licencias para el desarrollo del Software Libre y Abierto: Buenas prácticas
Articulo relacionado: Calidad Técnica: Buenas prácticas en el desarrollo del Software Libre
Articulo relacionado: Buenas prácticas para desarrollar Software libre y abierto: Documentación
Secure Code Wiki: Buenas prácticas de codificación segura
¿Qué es Secure Code Wiki?
Tal como dice textualmente su sitio web:
“Secure Code Wiki es una culminación de las prácticas de codificación segura para una amplia gama de lenguajes.”
Y estás buenas prácticas y el sitio web de «Secure Code Wiki» han sido creados y mantenidos por una organización india llamada Payatu.
Ejemplos de Buenas Prácticas por tipos de Lenguajes de Programación
Dado que, el sitio web se encuentra en inglés, mostraremos algunos ejemplos de codificación segura sobre diversos lenguajes de programación, algunos libres y abiertos, y otros privativos y cerrados, ofrecidos por dicho sitio web para explorar el potencial y la calidad del contenido cargado.
Además, es importante resaltar que las Buenas Prácticas mostradas sobre las Plataformas de Desarrollo siguientes:
- .NET
- Java
- Java For Android
- Kotlin
- NodeJS
- Objective C
- PHP
- Python
- Ruby
- Swift
- WordPress
Son divididas en las siguientes categorías para Lenguajes de Escritorio:
- A1 – Inyección (Injection)
- A2 – Autenticación rota (Broken Authentication)
- A3 – Exposición de datos sensibles (Sensitive Data Exposure)
- A4 – Entidades externas XML (XML External Entities / XXE)
- A5 – Control de acceso defectuoso (Broken Access Control)
- A6 – Desconfiguración de la seguridad (Security Misconfiguration)
- A7 – Secuencia de comandos en sitios cruzados (Cross-Site Scripting / XSS)
- A8 – Deserialización insegura (Insecure Deserialization)
- A9 – Uso de componentes con vulnerabilidades conocidas (Using Components with Known Vulnerabilities)
- A10 – Registro y supervisión insuficientes (Insufficient Logging & Monitoring)
Y también divididas en las siguientes categorías para Lenguajes Móviles:
- M1 – Uso inadecuado de la plataforma (Improper Platform Usage)
- M2 – Almacenamiento inseguro de datos (Insecure Data Storage)
- M3 – Comunicación insegura (Insecure Communication)
- M4 – Autenticación insegura (Insecure Authentication)
- M5 – Criptografía insuficiente (Insufficient Cryptography)
- M6 – Autorización insegura (Insecure Authorization)
- M7 – Calidad del código del cliente (Client Code Quality)
- M8 – Manipulación del código (Code Tampering)
- M9 – Ingeniería inversa (Reverse Engineering)
- M10 – Funcionalidad extraña (Extraneous Functionality)
Ejemplo 1: .Net (A1- Inyección)
El uso de un mapeador relacional de objetos (ORM) o de procedimientos almacenados es la forma más eficaz de contrarrestar la vulnerabilidad de inyección SQL.
Ejemplo 2: Java (A2 – Autenticación rota)
En la medida de lo posible, implemente la autenticación multifactorial para evitar ataques automatizados, de relleno de credenciales, de fuerza bruta y de reutilización de credenciales robadas.
Ejemplo 3: Java For Android (M3 – Comunicación insegura)
Es imprescindible aplicar SSL/TLS a los canales de transporte utilizados por la aplicación móvil para transmitir información sensible, tokens de sesión u otros datos sensibles a una API backend o servicio web.
Ejemplo 4: Kotlin (M4 – Autenticación insegura)
Evite los patrones débiles
Ejemplo 5: NodeJS (A5 – Control de acceso defectuoso)
Los controles de acceso del modelo deben imponer la propiedad de los registros, en lugar de aceptar que el usuario pueda crear, leer, actualizar o eliminar cualquier registro.
Ejemplo 6: Objective C (M6 – Autorización insegura)
Las aplicaciones deben evitar el uso de números adivinables como referencia de identificación.
Ejemplo 7: PHP (A7 – Secuencia de comandos en sitios cruzados)
Codifica todos los caracteres especiales usando htmlspecialchars() o htmlentities() [si está dentro de las etiquetas html].
Ejemplo 8: Python (A8 – Deserialización insegura)
El módulo pickle y jsonpickle no es seguro, nunca lo uses para deserializar datos no confiables.
Ejemplo 9: Python (A9 – Uso de componentes con vulnerabilidades conocidas)
Ejecutar la aplicación con el usuario con menos privilegios
Ejemplo 10: Swift (M10 – Funcionalidad extraña)
Eliminar la funcionalidad de puerta trasera oculta u otros controles de seguridad internos de desarrollo que no están destinados a ser liberados en un entorno de producción.
Ejemplo 11:WordPress (XML-RPC Disable)
XML-RPC es una función de WordPress que permite la transferencia de datos entre WordPress y otros sistemas. En la actualidad ha sido sustituida en gran medida por la API REST, pero aún se incluye en las instalaciones por compatibilidad con versiones anteriores. Si está activado en WordPress, un atacante puede realizar ataques de fuerza bruta, pingback (SSRF), entre otros.
Fuente: desdelinux
