Springe zum Hauptinhalt

2010-03: Java-Frameworks gefährden die Sicherheit

Ses­si­on Fi­xa­ti­on“-­An­grif­fe funk­tio­nie­ren so: Ein An­grei­fer star­tet ei­ne Ver­bin­dung mit dem Webser­ver und er­hält da­mit ei­ne Ses­sion­-­I­D. Die­se schiebt er (bei­spiels­wei­se per XSS) ei­nem Op­fer zu, das sich auf dem Webser­ver au­then­ti­fi­zier­t. Die Ses­si­on des An­grei­fers ist nun au­then­ti­fi­zier­t, der An­grei­fer kann mit den Rech­ten des Op­fers auf das Sys­tem zu­grei­fen. Ele­gant.

Und eben­so ele­gant zu ver­mei­den: Die Au­then­ti­fi­zie­rungs­rou­ti­ne er­stellt für die au­then­ti­fi­zier­te Ses­si­on ei­ne neue Ses­sion­-­ID und ver­wirft die bis­he­ri­ge Ses­si­on. Um ge­nau die­ses nicht stän­dig neu pro­gram­mie­ren zu müs­sen, ver­wen­den Ent­wick­ler Fra­me­works.

Bis­her wieg­ten ich die Nut­zer von be­währ­ten Ja­va­-­F­ra­me­works in Si­cher­heit. Auf ei­ne Pro­gram­mier­um­ge­bung, die täg­lich ein­ge­setzt wird von Hun­der­ten er­fah­re­nen Kol­le­gen, soll­te ja Ver­lass sein und sie soll­te kei­ne ge­fähr­li­chen Hin­ter­tür­chen öff­nen. Ganz an­ders als bei den ri­si­ko­freu­di­gen PHP­-­Kol­le­gen, die je­de Funk­ti­on im­mer wie­der neu er­fin­den.

Doch ein Ar­ti­kel in der iX be­rei­te­te nun ei­ner trü­ge­ri­schen Si­cher­heit ein En­de: Ses­si­on Fi­xa­ti­on ist mit­nich­ten ein rei­nes PHP­-­Pro­blem. Ei­ni­ge der be­lieb­tes­ten Ja­va­-­Serv­let­-­Con­tai­ner sind an­fäl­lig für die­se Schwach­stel­le. Scho­ckiert ver­nimmt der Pro­gram­mie­rer die Na­men be­kann­ter Ja­va­-­F­ra­me­works wie Tom­cat, JBoss und JO­nAS. Und bei rich­ti­ger In­ter­pre­ta­ti­on der CWE­-­Lis­te (Com­mon Weak­ness Enu­me­ra­ti­on) im­ple­men­tie­ren wohl auch ASP (Ac­ti­ve Ser­ver Pa­ge­s) und .net von Mi­cro­soft die An­mel­dung falsch.

Ei­ne Bla­ma­ge für die Ja­va­-­Gil­de. Im­mer­hin war die­se Schwach­stel­le be­reits 2004, al­so vor sechs Jah­ren, in den OWASP Top Ten er­wähnt, wie sie zu be­he­ben ist eben­so. Die CWE­-­Lis­te be­schreibt Pro­blem und auch Lö­sung in kla­ren Wor­ten: „In­va­li­da­te any exis­ting ses­si­on iden­ti­fi­ers pri­or to au­t­ho­ri­zing a new user ses­sion“. So ein­fach könn­te es sein.

Die ent­schei­den­de Fra­ge ist: Wie kann es ge­sche­hen, dass wich­ti­ge Kom­po­nen­ten, die tag­täg­lich zum Ein­satz kom­men, solch gra­vie­ren­de Feh­ler auf­wei­sen? Die für mich na­he­lie­gends­te Er­klä­rung wä­re, dass wahr­schein­lich ehe­ma­li­ge PHP­-­Pro­gram­mie­rer die Ja­va­-­F­ra­me­works ent­wi­ckelt ha­ben. Doch das wä­re nicht fair. Gleich­gül­tig wer die Ent­wick­ler der Fra­me­work­-­Bau­stei­ne sin­d: Sie soll­ten sich be­wusst ma­chen, dass es nicht nur dar­um geht, neue Fea­tu­res ein­zu­bau­en, son­dern dass die Er­geb­nis­se auch si­cher sin­d.

Üb­ri­gens: Ob Ihr Fra­me­work den Feh­ler ent­häl­t, kön­nen sie bei­spiels­wei­se mit dem Fi­re­fox Ad­d­-­On Live HTTP Hea­ders oder et­was ein­fa­cher mit Coo­kie­Sa­fe prü­fen. Wenn die ID im Ses­sion­-­Coo­kie nach der An­mel­dung die glei­che ist wie vor­her, dann ist Ih­re An­wen­dung an­fäl­lig. Ge­gen­maß­nah­men für die Ja­va­-­F­ra­me­works be­schreibt be­sag­ter Ar­ti­kel.

Portrait von Hartmut Goebel

Hartmut Goebel

Diplom-Informatiker, CISSP, CSSLP, ISO 27001 Lead Implementer

Haben Sie noch Fragen?
Anruf oder Mail genügt:
  +49 871 6606-318
  +49 175 29 78 072
  h.goebel@goebel-consult.de