Secu­re Coding ist nicht mehr neu in der Soft­ware­ent­wick­lung. Es ist auch längst eta­bliert, man fin­det reich­hal­ti­ge Infor­ma­tio­nen dazu, es gibt Kur­se, Tuto­ri­als, und alles ist bes­tens doku­men­tiert. Alle Ent­wick­le­rin­nen und Ent­wick­ler soll­ten es daher schon längst ein­set­zen. Lei­der beginnt die Ent­wick­lung siche­rer Soft­ware nicht mit einer ein­fa­chen To-Do Lis­te und kann nicht ohne die not­wen­di­ge Unter­stüt­zung auf allen Ebe­nen moder­ner Anwen­dun­gen bewäl­tigt wer­den, die aus einer Viel­zahl von Kom­po­nen­ten und Wech­sel­wir­kun­gen bestehen. War­um das so ist und wie man begin­nen kann, wol­len wir hier kurz skizzieren.

Code ist auf sich allei­ne gestellt

Wenn Code ein­mal die Ent­wick­lungs- und Test­um­ge­bung ver­las­sen hat, dann muss die­se zur Lauf­zeit allei­ne und ohne Auf­sicht funk­tio­nie­ren. Com­pu­ter­sys­te­me sind ja genau für auto­ma­ti­sier­te Pro­zes­se, die größ­ten­teils unbe­auf­sich­tigt durch­ge­führt wer­den. Nur in Feh­ler- oder Aus­nah­me­fäl­len erzeugt Soft­ware Mel­dun­gen bzw. Ergeb­nis­se, die dann von einem Men­schen bear­bei­tet wer­den müs­sen. Man muß also bei der Ent­wick­lung mög­lichst gut zu Zukunft vor­aus­se­hen und Situa­tio­nen vor­beu­gen, die mög­li­cher­wei­se auf­tre­ten kön­nen. Genau da beginnt der Bereich, in dem poten­ti­el­le Sicher­heits­lü­cken ein gutes Ver­steck finden.

Um unbe­kann­te Bedro­hun­gen zu illus­trie­ren, wird ger­ne das Inter­net zitiert. Tat­säch­lich kann man jed­we­de Pro­duk­ti­ons­um­ge­bung zu die­sem Zweck ver­wen­den, denn selbst im auf­ge­räum­tes­ten Netz­werk fin­det man aus­rei­chend kom­ple­xe Pro­to­kol­le, Daten und Situa­tio­nen, die nicht geplant waren. Soft­ware darf in kei­ner Umge­bung ver­sa­gen. Der Pro­gramm­ab­lauf muss zu jeder Zeit einen kon­sis­ten­ten Zustand vor­fin­den. Eine Test­um­ge­bung muss die­sem Umstand Rech­nung tra­gen. Dabei darf man nicht ver­ges­sen, dass Soft­ware mit­un­ter Jah­re oder Jahr­zehn­te im Ein­satz ist. Bei die­sen Zeit­span­nen kann man nicht alles vor­her­se­hen. Bes­tes Bei­spiel sind Stan­dards und Spe­zi­fi­ka­tio­nen. Uni­code ist ein Indus­trie­stan­dard für kon­sis­ten­tes Kodie­ren, Reprä­sen­tie­ren und Bear­bei­ten von Text der meis­ten welt­weit ein­ge­setz­ten Schrif­ten. Der aktu­el­le Stan­dard 11.0 von 2018 besteht aus 137.374 Zei­chen. Im Ver­gleich zur Ver­si­on 10.0 aus dem Jahr 2017 sind 684 neue Zei­chen hin­zu­ge­kom­men. Wie vie­le wer­den es im nächs­ten Stan­dards sein, wel­che Bedeu­tung wer­den sie haben, und wel­che Codes wer­den ihnen zuge­ord­net? Darf mei­ne Appli­ka­ti­on den­noch von sich behaup­ten Uni­code-Unter­stüt­zung zu beherr­schen? Man kann sich also getrost in aktu­el­ler Soft­ware Gedan­ken machen, was genau mit unbe­kann­ten Kodie­run­gen zu tun ist, weil die­ses Pro­blem bestehen blei­ben wird. Fäl­le wie die­se las­sen sich mit belie­bi­gen Daten­for­ma­ten und Über­tra­gungs­pro­to­kol­len wiederholen.

Kon­sis­ten­te Zustände

Eine Appli­ka­ti­on soll ste­tig und stän­dig kon­sis­tent sein. Die­se theo­re­ti­sche Anfor­de­rung ist ein guter Start in die Welt des Secu­re Coding und Secu­re Design. Code besteht aus Kom­po­nen­ten und läuft in der Regel mit Hil­fe eines Betriebs­sys­tems. Das bedeu­tet, dass dau­ernd Funk­tio­nen auf­ge­ru­fen wer­den, die Res­sour­cen bear­bei­ten oder Auf­ga­ben ver­tei­len. Sofern alle Ope­ra­tio­nen feh­ler­los durch­ge­führt wer­den kön­nen, gibt es bei den Feh­ler­ab­fra­gen nichts zu tun. Nur die eige­nen Daten­struk­tu­ren des Codes müs­sen unter­hal­ten wer­den. Das ist die ers­te Auf­ga­be der Ent­wick­ler. Auch hier ist krea­ti­ves Den­ken gefor­dert. Was pas­siert, wenn das Pro­gramm nicht been­det wird? Wir haben in Pro­duk­tiv­um­ge­bun­gen schon Sys­te­me gese­hen, die seit 7 Jah­ren unun­ter­bro­chen im Ein­satz sind. Spe­zi­ell bei Tele­fon­an­la­gen oder Infra­struk­tur ist dies häu­fig zu beob­ach­ten. Das bedeu­tet mehr als 220.752.000 Sekun­den Ablauf von Instruk­tio­nen, Daten­zu­grif­fe und ‑ver­ar­bei­tung. Unit Tests kön­nen sol­che Sze­na­ri­en nicht abbil­den, weil die Zei­ten zu lan­ge und dadurch die Mög­lich­kei­ten der Code-Pfa­de zu viel­fäl­tig sind.

Fokus auf Ausnahmesituationen

Sind die Daten „nor­mal“, so wer­den Tests in der Regel funk­tio­nie­ren und Feh­ler fin­den. In den Rand­ge­bie­ten, wo Aus­nah­me­si­tua­tio­nen herr­schen, wird es für jede Appli­ka­ti­on span­nend. Der Sinn von Test­fäl­len ist ja das Auf­spü­ren von Soft­ware Bugs und das Detek­tie­ren, ob beho­be­ne Feh­ler auch sol­che blei­ben. Bei Secu­re Coding möch­te man jedoch den Code mit Situa­tio­nen for­dern, die noch nicht auf­ge­tre­ten sind. Das lässt sich nur mit auto­ma­ti­sier­ten Tests errei­chen, die ste­tig Ein­ga­be­da­ten ver­än­dern und prü­fen, ob die Soft­ware damit zurecht­kommt. Die Metho­de nennt sich Fuz­zing. Sie ist schon sehr alt und stammt aus der Zeit der Loch­kar­ten. Damals hat man defek­te und absicht­li­che abge­kleb­te bzw. zusätz­lich geloch­te Loch­kar­ten als Ein­ga­be ver­wen­det. In der Infor­ma­tik hat die­ser Ansatz in den letz­ten Deka­den eine Renais­sance erlebt. Fuz­zing zählt heu­te zum Stan­dard­re­per­toire der Softwareentwicklung.

Der Ein­stieg ist denk­bar ein­fach, da man ja ohne­hin bei Con­ti­nuous Inte­gra­ti­on und Build Tests Auto­ma­ti­ken hat. Fuz­zing erwei­tert die­sen Pro­zess um algo­rith­misch zufäl­lig vari­ier­te Ein­ga­ben. Aus­gangs­ba­sis sind nor­ma­le Daten, die man als Bei­spiel ver­wen­det. Man kann den Test­kor­pus zusätz­lich mit Extre­men anrei­chern (beson­ders gro­ße, ver­schach­tel­te oder sons­ti­ge Daten, die übli­cher­wei­se nie/selten auf­tre­ten, jedoch an die Gren­zen des Daten­for­mats gehen). Der Vor­teil ist das Tes­ten ohne Betreu­ung sowie die Gene­rie­rung von wei­te­ren Test­da­ten, falls der Pro­zess Feh­ler gefun­den hat. Die Inte­gra­ti­on von Fuz­zing ist der leich­tes­te Ein­stieg in das The­ma Secu­re Coding. Fin­den Sie die Daten, die Ihre Anwen­dung bedro­hen, bevor es die Angrei­fer tun.

René Pfeif­fer ist frei­er Mit­ar­bei­ter bei SEC4YOU im Bereich Pene­tra­ti­on Test­ing, IT-Sicher­heits­be­ra­tung und Secu­re Coding. Regel­mä­ßig beweißt er sei­ne Kom­pe­tenz in anspruchs­vol­len Secu­ri­ty Pro­jek­ten. Für Fra­gen errei­chen Sie René Pfeif­fer über unse­re Kon­takt­mög­lich­kei­ten.

Pas­sen­de Pro­duk­te aus dem SEC4YOU Shop