Programació defensiva

La programació defensiva (defensive programming en anglés) és una forma de disseny defensiu aplicada al disseny de software que busca garantisar el comportament de tot element d'una aplicació davant qualsevol situació d'us per incorrecta o imprevisible que esta puga semblar. En general, açò supon multiplicar les comprovacions que es realisen en tots els mòduls programats, en la consegüent penalisació en càrrega de processador, temps i aument en la complexitat del còdic. Les tècniques de programació defensiva s'utilisen especialment en components crítics el mal funcionament dels quals, ya siga per descuit o per atac maliciós, podria carrejar conseqüències greus o danys catastròfics.

La programació defensiva és un enfocament que busca millorar el software i el còdic font, en térmens de:

• Calitat - reduint el número de fallos de software i, en conseqüència, problemes.
• Fent el còdic font comprensible - el còdic font deu ser llegible i comprensible, a prova d'una auditoria de còdic.
• Fer que el software es comporte d'una manera predible pese a entrades o accions d'usuari inesperades.

Programació segura

La programació defensiva és algunes voltes referida com a programació segura pels científics de computació els quals ubiquen este enfocament minimisant errors de software.

Els errors de software (bugs) poden ser potencialment usats per un cracker (nomenats hacker per confusió) per a una injecció de còdic, atacs de refús de servici o un atre atac.

Una diferència entre programació defensiva i pràctiques normals és que poques hipòtesis són fetes pel programador, el qual intenta manejar tots els possibles estats d'error. En resum, el programador mai assumix que una cridada a una funció particular o biblioteca treballarà baix les entrades previstes.

Tècniques de programació defensiva

Ací estan algunes tècniques de programació defensiva sugerides per alguns dels científics líders de computació per a evitar crear problemes de seguritat i errors de software. Estos científics afirmen que encara que este procés puga millorar la calitat el còdic, no és suficient per a assegurar la seguritat.

Reduir complexitat del còdic font

Mai fer el còdic més complex de lo necessari. La complexitat genera bugs, incloent problemes de seguritat. Esta meta pot tindre conflicte en l'objectiu d'escriure programes que puguen recuperar-se de qualsevol error i manejar qualsevol entrada de senyes. Manejar totes les ocurrències inesperades en un programa requerix que el programador afigga còdic extra, el qual poguera també tindre bugs.

Revisions del còdic font

Una revisió de còdic és a on algú diferent a l'autor original realisa una auditoria de còdic. Una auditoria de còdic feta pel mateix creador és insuficient. L'auditoria la deu fer algú que no siga l'autor, com quan s'escriu un llibre, deu ser revisat per algú que no siga l'autor.

Simplement fent el còdic disponible per a que uns atres ho lligguen (software lliure) és insuficient, puix no hi ha garantia que el còdic siga efectivament revisat, no deixant que siga rigorosament revisat.

Proves de software

Les proves de software deuran ser para tant que el software treballe com deu, com quan se supon que passe si es realise deliberadament males entrades.

Les ferramentes de prova poden capturar entrades de teclat associades en operacions normals. Després les cadenes de text d'estes entrades capturades poden ser copiades i editades per a ensajar totes les permutació i combinacions, després ampliar-les per a tests posteriors despuix de qualsevol modificació-. Els defensors de la clau de registre afirmen que els programadors que usen este método deuran assegurar que les persones a les quals se'ls estan capturant les entrades estiguen al tant d'açò, i en que propòsit?, per a evitar acusacions de violació de privacitat .

Reutilisació inteligent del còdic font

Si és possible, reutilisar còdic. L'idea és capturar beneficis d'un ben escrit i ben provat còdic font, en lloc de crear bugs innecessaris.

No obstant, reutilisar còdic no sempre és la millor manera de progressar, particularment quan la llògica del negoci està involucrada. Reutilisar en este cas pot causar sérios bugs en els processos de negoci.

Els problemes de llegat

Abans de reutilisar còdic font vell, bibliotecas, APIs, configuració i demés, deu ser considerat si el treball anterior és vàlit per a reutilisar, o si és propens a problemes de llegat.

Els problemes de llegat són problemes inherents quan s'espera que vells dissenys treballen en els requeriments actuals, especialment quan estos vells dissenys no varen ser desenrollats o provats en estos requeriments en ment.

Molts productes de software han experimentat problemes en vells còdics font llegats, per eixemple:

• El còdic llegat pugues no haver segut dissenyat baix iniciativa de Programació Defensiva, i pot per tant ser de molta menys calitat que un disseny més nou de còdic font.
• El còdic llegat pugues haver segut escrit i provat baix condicions que ya no apliquen més. Els vells test d'assegurament de calitat poden no ser vàlits ara. Eixemple 1: El còdic llegat pugues haver segut dissenyat per a entrades ASCII pero ara l'entrada és UTF-8. Eixemple 2: El còdic llegat pugues haver segut compilado i provat sobre arquitectura de 32 bits, pero quan és compilado sobre arquitectura de 64 bits poden ocórrer nous problemes aritmètics. Eixemple 3: Un còdic llegat pugues haver-se enfocat cap a màquines fòra de llínea, pero es torna vulnerable una volta la conectivitat de ret és adicionada.
• El còdic llegat no és escrit en nous problemes en ment. Per eixemple, còdic font escrit en 1990, pot ser propens a vulnerabilitats d'Injecció de Còdic, perque molts d'estos problemes no eren extensament entesos en eixa época.

Eixemples notables de problemes de llegat:

• BIND 9, presentat per Paul Vixie i David Conrad com “BINDv9 és una completa reescritura”, “La seguritat va ser una consideració clau en disseny”, nomenant seguritat, robustea, escalabilidad i nous protocols com a preocupacions clau per a reescriure vell còdic llegat.
• Microsoft Windows va sofrir de el “Windows Metafile Vulnerability” i atres explotacions referents al format WMF, El centre de resposta de seguritat de Microsoft descriu que característiques de WMF com “ Al voltant de 1990, el soport WMF va ser adicionado…. Est va ser un temps diferent en el paisage de seguritat….estàvem tots completament confiats….”.
• Oracle està combatent problemes de llegat, com el vell còdic font escrit sense direccional preocupacions respecte a l'injecció SQL i Escales de Privilegi, resultant en moltes vulnerabilitats de seguritat les quals han pres temps en ser arreglades i han generat apanys incomplets. Açò li ha alçat pesades crítiques dels experts de seguritat com David Litchfield, Alexander Kombrust, César Tancat. Una crítica adicional és que les instalacions per defecte (largamente un llegat de velles versions) no es troba alineat en les seues pròpies recomanacions de seguritat, com l'Oracle Database Security Checklist, el qual és difícil d'esmenar.

Canonicalizar

Els crackers tendixen a buscar representacions diferents de les mateixes senyes.

Per eixemple, si un programa verifica un nom d'archiu contra /etc/passwd, un cracker pot intentar usar un nom diferent pero que es referix al mateix archiu, com /etc/./passwd.

Per a evitar bugs per entrades no canòniques, es deuen amprar les API de canonicalización.

Principi del menor privilegie

Amprar el principi del menor privilegi, Evitar tindre software corrent en un modo privilegiat:

• Mai fer programes UNIX setuid a menos que s'estiga realment segur que s'està protegint la seguritat.
• Mai fer programes de Windows córrer com a servicis de sistema local a menos que s'estiga realment segur que s'està protegint la seguritat.
• No concedir més permissos que els necessaris a grans grups d'usuaris o públic/qualsevol.

• No concedir més permissos que els necessaris a grups menuts d'usuaris o usuaris específics.
• Preferir concedir permissos a grups menuts d'usuaris o usuaris específic, en lloc de concedir-los a grans grups d'usuaris o públic/qualsevol. És millor que uns pocs usuaris tinguen més permissos, que molts usuaris tinguen major permís.

Baixa tolerància contra errors potencials

Assumir que el còdic construït que sembla ser propens a problemes (similars a conegudes vulnerabilitats, etc), són errors (bugs) o potencials fallos de seguritat. La regla bàsica és: “No estic al tant de tots els tipos d'explotacions de seguritat” Dec protegir en contra de lo que conec i aixina tinc que ser proactivo”

Atres tècniques

• Un dels problemes més comuns és us no verificat d'estructures de tamany constant i funcions de tamany de senyes dinàmiques (el problema del desbordament de búfer). Açò és especialment comú en la gestió de cadenes de text en llenguage C. Les funcions de biblioteca C com gets mai deurien ser usades si el tamany màxim del búfer d'entrada no es passa com a argument. Les funcions de biblioteca en C com scanf poden ser usades segurament, pero requerixen que el programador vaja en conte en la selecció dels formats segurs de strings, cuidant-se abans d'usar-los.
• Sifrar/ Autenticar totes les senyes importants transmés sobre les rets. No intentar implementar un propi esquema de sifrat, pero usar un ya provat.
• Totes les senyes són importants fins que es demostre lo contrari.
• Totes les senyes estan viciats fins que es demostre lo contrari.
• Tot còdic és insegur fins que es demostre lo contrari.
• Si les senyes són provades per correctitud, verificar que estan correctes, no que estan incorrectes.
• Disseny per contracte: El disseny per contracte usa precondiciones, postcondiciones i invariantes per a assegurar que les senyes proveïdes (i l'estat del programa com un tot) esta saneado. Açò permet al còdic documentar totes les hipòtesis i fer-ho aixina segur. Açò pot envoldre la verificació d'arguments a una funció o método per a validar abans d'eixecutar el cos de la funció. Despuix del cos de la funció, fer un chequeo de l'estat de l'objecte (en llenguages de programació orientada a objectes) o guardar les senyes i el valor de tornada, ans que ixca de la mateixa (break/ return/ throw/ error code) és també sapient.
• Asserció: Entre funcions, es pot voler verificar que s'està referenciando alguna cosa que no és vàlit (ej: null) i que el tamany dels apanys són vàlits abans de referenciar elements, especialment instanciando de forma temporal/local. Una bona heurística és no creure en les biblioteques que s'hagen o no s'hagen escrit. Cada volta que es criden estes, verificar lo que es vol que estes tornen. A voltes ajuda crear una chicoteta biblioteca de funcions de “asserció” i “verificació” per a fer-la junt a un logger, per a aixina poder traçar la ruta i reduir la necessitat d'extensos cicles de depuració. En l'arribada de biblioteques de loggeo i la Programació orientada a l'Aspecte, molts dels tediosos aspectes de la programació defensiva són mitigats.
• Preferir l'us d'excepcions programables front a la sobrecàrrega dels valors de tornada enviant com a valors no útils còdics d'error.