Secure Code Wiki: Una web de buenas prácticas de codificación segura

Secure Code Wiki: Una web de buenas prácticas de codificación segura

Secure Code Wiki: Una web de buenas prácticas de codificación segura

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

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.Licencias para el desarrollo del Software Libre y Abierto: Buenas prácticas

Artículo relacionado:
Licencias para el desarrollo del Software Libre y Abierto: Buenas prácticas

Artículo relacionado:
Calidad Técnica: Buenas prácticas en el desarrollo del Software Libre
Artículo relacionado:
Buenas prácticas para desarrollar Software libre y abierto: Documentación

Secure Code Wiki: Buenas prácticas de codificación segura

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.

Imagen generica para conclusiones de artículos

Conclusión

Esperamos que esta pequeña y útil publicación sobre el sitio web llamado «Secure Code Wiki», el cual ofrece un valioso contenido relacionado con las «Buenas Prácticas de Codificación Segura»; sea de mucho interés y utilidad, para toda la «Comunidad de Software Libre y Código Abierto» y de gran contribución a la difusión del maravilloso, gigantesco y creciente ecosistema de aplicaciones de «GNU/Linux».

Por ahora, si te ha gustado esta publicación, no dejes de compartirla con otros, en tus sitios web, canales, grupos o comunidades favoritas de redes sociales o sistemas de mensajería, preferiblemente libres, abiertas y/o más seguras como TelegramSignalMastodon u otra del Fediverso, preferiblemente.

Y recuerda visitar nuestra página de inicio en «DesdeLinux» para explorar más noticias, además de unirte a nuestro canal oficial de Telegram de DesdeLinuxMientras que, para mayor información, puedes visitar cualquier Biblioteca en línea como OpenLibra y JedIT, para acceder y leer libros digitales (PDFs) sobre este tema u otros.


El contenido del artículo se adhiere a nuestros principios de ética editorial. Para notificar un error pincha aquí.

Un comentario, deja el tuyo

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   luix dijo

    Interesante articulo, deberia ser obligatorio para todo developer..