Vast hun cookies of sessies niet niet safe hebben gemaakt. Want als je
het alleen mogelijk maakt voor SSL kan het niet door javascript of andere
taal worden gelezen. Alleen via de SSL protocol ;)

Nielsk

Zo te zien ben je dan 3x geklopt door de computercriminelen...

Denk dat 1 keer genoeg was om te zien dat het onveilig was. Zoiezo is SSL
alleen niet goed je moet het ook goed in elkaar steken.

Nielsk

Wat een hoop mensen maar niet lijken te begrijpen is dat SSL de site zelf niet veilig(er) maakt. Alleen het verkeer van/naar de server.

Session layer encryptie van de DATA pakketten..

Onbegrijpelijk, dat
kennelijk een aantal mailservers niet op voor mail malafide
HTML-code controleren en dat derden bij enige Europese
banken eigen code kunnen injecteren.
Rechtsonder in de bij het oorspronkelijke
artikel getoonde afbeelding is duidelijk een gebroken
slotje te zien, wanneer men Mozilla Firefox gebruikt.
http://news.netcraft.com/archives/2008/01/08/fideura.png

De afbeelding hierboven in dit forum toont een gouden slotje
in MSIE.

Dat laatste duidelijk ook niet,
gelet op de kennelijk geprepareerde URL verzonden over een
ssl-verbinding. Het verkeer van en naar de server wordt
versleuteld om onderschepping te bemoeilijken, maar zegt
verder geheel niets over de aard van dat verkeer of over de
veiligheid van een site of dat van de UA.

Of je er de authenticiteit van de getoonde content mee kunt
controleren is mede afhankelijk van de gebruikte UA, zo zou
mede blijken.

Correct en dat bedoelde ik ook ;)

Het gebeurt zo vaak dat (beveiligde) websites ook
onbeveiligde content via frames laat zien.
Daar krijg je de eerste keer een melding van, maar iedereen
zet het uit om gewaarschuwd te worden wanneer de pagina
/gemengd/ongemengd is.

Op die manier kan je dus via de onveilige content zaken
manipuleren.

Dat "gouden" slotje kan echter ook gewoon een plaatje zijn.
Alleen op het slotje letten is dus ook niet alles wat je moet doen (volgens
veel banken echter wel).

Als je de aanval niet begrijpt, dan is het altijd moeilijk
om een oplossing te verzinnen. In dit geval heeft het niets
met cookies te maken, maar worden de ingevulde credentials
ergens anders naar toe gepost.

hahahahaha ! Een italiaanse bank met ssl met mirc scripting ? ohhh
geen wonder dat er een [color=red] cross-scripting lek in zit[/color]

Op Secunia (http://secunia.com/advisories/21172/) lees
je: Input passed to the "Expect:" header is not properly
sanitised before being returned to users. This can be
exploited to execute arbitrary HTML and script code in a
user's browser session in context of a vulnerable site..

Paul Mutton zegt: This particular attack is made all the
more convincing by the vector used by the fraudsters: the
URL employed by the attack injects a series of numbers
directly into a JavaScript function call that already exists
on the bank's LoginServlet page.

Het hangt er van af hoe goed dat injecteren dus lukt in je
browser. De url wijst volgens mij van een ander domein dan
het domein van de bank zelf. Je opent tenslotte vanuit de
e-mail. Dus werkt het dan ook als je browser standaard
Javascript standaard tegenhoudt, maar alleen toestaat aan
vertrouwde sites?
En houdt een phishing-filter in je browser dit tegen?

Dus voor al die mensen die overal op klikken zouden dit
soort standaardinstellingen misschien beter zijn. Maar het
gaat ten koste van enig gebruiksgemak want de vertrouwde
sites moeten wel actief bekend gemaakt worden in de browser.
De doorsneegebruikers die ik ken, vinden dit al teveel werk.

Misschien moeten overheden dit soort beveiliging eens
promoten. Net als die spotjes over het afsluiten van ramen &
deuren, moet men de massa beter bewust zien te krijgen van
dit soort eenvoudige mogelijkheden om zelf de computer beter
op slot te doen.

de ontwikkelkaar(s) wellicht..?

Fred

'k Ben het met 'Anoniem'/Fred eens Nielsk. SSL heeft geen
toegevoegde waarde meer als je d.m.v. een geprepareerde URL
zelf JavaScript en/of HTML kan toevoegen aan een site. SSL
beschermt hier ook niet tegen.

Gegroet,
Barry Pouwels


ps 'k Weet wel degelijk waar ik over praat. Zoek eens op m'n
naam op bijv. Google.

Dat klopt. De authenticiteit van de site van de bank en
diens content is met behulp van de fingerprint van het
certificaat te bepalen, mits de bank deze aan de klant via
andere wegen kenbaar heeft gemaakt, bijvoorbeeld per brief.
Toch zullen de meeste mensen puur op het in de UA getoonde
slotje afgaan of dat uiteindelijk gaan doen.

De UA moet in principe controleren of alle content van
dezelfde bron afkomstig is, gebruikmakend van dezelfde (bij
voorkeur door de gebruiker geratificeerde) certificaat en
afwijkingen aan de gebruiker kenbaar maken, bij voorkeur
nadrukkelijk, en die de gebruiker niet uit kan zetten. Te
denken aan enigszins dominante signalering bij
onversleutelde items op de 'beveiligde' https pagina en
zeker bij items van een andere bron afkomstig. UA's maken
dit in meer of mindere mate al kenbaar wanneer dit het geval
is, maar behoeft kennelijk verbetering.

Dat is erg
slordig en ondermijnt het doel van SSL certificaten omdat
voor de bezoeker dan niet in een oogopslag duidelijk is
welke items wel en welke items niet onder dat certificaat
vallen, laat staan welke items van een malafide bron
afkomstig zijn.
Waarmee het nut van SSL
certificaten definitief verdampt omdat de kans dan groot is
dat gebruikers de melding bij andere site's nonchalant
wegklikken.

Ik citeer:
"Deze aanval bewijst de ernst cross-site scripting lekken op banksites"

Waardoor is het lek dus door ontstaan?

Het lek is tweeledig.
Het lek is ontstaan in (vermoedelijk) apache, maar al gepatched.
Dus vermoedelijk hebben de beheerders hun machines niet op tijd
geupdate.
Door het lek in de web-server kunnen slechte urls naar browsers gestuurd
worden. Hoe die daarmee omgaan, hangt van de browser af en van de
instellingen waarmee die browser werkt.