Cross-scripting lek in banksite maakt SSL zinloos

10-01-2008,

13:43 door

Anoniem

+0 Rating:

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

10-01-2008,

13:45 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

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

10-01-2008,

14:11 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

Door Anoniem
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

10-01-2008,

14:13 door

SirDice

+0 Rating:

Quote deze reactie | Reactie niet OK

Het laat zien dat veiligheid niet gegarandeerd wordt door de aanwezigheid van 'https' aan het begin van een URL, of te controleren of de adresbalk wel de juiste domeinnaam bevat", zegt Paul Mutton van Netcraft.

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.

10-01-2008,

14:20 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

Session layer encryptie van de DATA pakketten..

10-01-2008,

14:34 door

Sebastián

+0 Rating:

Quote deze reactie | Reactie niet OK

De oplichters hebben de afgelopen dagen massaal
phishing e-mails verstuurd met een geprepareerde URL
die een vervalst formulier op de loginpagina van de bank
injecteerde.
(...)
Toch is het de criminelen gelukt om een IFRAME op de
loginpagina te plaatsen, die een aangepast loginvenster
van een server in Taiwan laadt.

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.

Ook in dit geval zou het gouden slotje gewoon getoond
worden.

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.

10-01-2008,

15:27 door

Sebastián

+0 Rating:

Quote deze reactie | Reactie niet OK

Door SirDice

Het laat zien dat veiligheid niet gegarandeerd wordt
door de aanwezigheid van 'https' aan het begin van een URL,
of te controleren of de adresbalk wel de juiste domeinnaam
bevat", zegt Paul Mutton van Netcraft.

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.

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.

10-01-2008,

15:31 door

SirDice

+0 Rating:

Quote deze reactie | Reactie niet OK

Door Sebastián
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.

Correct en dat bedoelde ik ook ;)

10-01-2008,

15:54 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

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.

10-01-2008,

16:12 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

Door Sebastián
De afbeelding hierboven in dit forum toont een gouden slotje
in MSIE.

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).

10-01-2008,

16:28 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

Door Anoniem
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

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.

10-01-2008,

17:57 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

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

10-01-2008,

18:23 door

Nielsk

+0 Rating:

Quote deze reactie | Reactie niet OK

Door Anoniem

Door Anoniem
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

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.

Kan ook maar ik weet wel degelijk wel wat van XSS :) Jij zal
wel die Paul Wilder wannabee gast zijn die me ook op het
forum probeert af te kraken.

Wat in het nieuws staat is gewoon een vorm van phising niets
meer of minder maar dit lek is veroorzaakt door..... Zeg
het maar, toe maar ;)

10-01-2008,

19:39 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

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.

10-01-2008,

20:39 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

Door Nielsk

Door Anoniem

Door Anoniem
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

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.

Kan ook maar ik weet wel degelijk wel wat van XSS :) Jij zal
wel die Paul Wilder wannabee gast zijn die me ook op het
forum probeert af te kraken.

Wat in het nieuws staat is gewoon een vorm van phising niets
meer of minder maar dit lek is veroorzaakt door..... Zeg
het maar, toe maar ;)

de ontwikkelkaar(s) wellicht..?

Fred

11-01-2008,

10:22 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

'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.

11-01-2008,

11:24 door

Sebastián

+0 Rating:

Quote deze reactie | Reactie niet OK

Door Anoniem
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).

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.

Door Anoniem
Het gebeurt zo vaak dat (beveiligde) websites ook
onbeveiligde content via frames laat zien.

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.

Daar krijg je de eerste keer een melding van, maar
iedereen zet het uit om gewaarschuwd te worden wanneer de
pagina /gemengd/ongemengd is.

Waarmee het nut van SSL
certificaten definitief verdampt omdat de kans dan groot is
dat gebruikers de melding bij andere site's nonchalant
wegklikken.

11-01-2008,

13:03 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

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

Waardoor is het lek dus door ontstaan?

11-01-2008,

13:38 door

Anoniem

+0 Rating:

Quote deze reactie | Reactie niet OK

Door Anoniem
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.

E-mail:
Wachtwoord:
Blijf 30 dagen ingelogd
Wachtwoord kwijt? Account aanmaken