Tiistai, 10.2.2004
IE-päivitys poistaa tuen URL-autentikoinnille
Microsoftin helmikuun 2. päivä julkaisema tietoturvapäivitys on aiheuttanut monille Internet Explorer -selaimen käyttäjille hämmennystä, sillä päivityksen jälkeen tunnus:salasana@domain.com-syntaksia käyttävät URL-linkit ovat lopettaneet toimintansa. Microsoft toteaa julkistamassaan artikkelissa poistaneensa tuen URL-käyttäjätunnistukselle täysin tietoisesti, koska uudemmissa IE-selaimissa ominaisuutta voidaan käyttää väärin yhdessä joulukuussa löytyneen tietoturvareiän kanssa ja harhauttaa käyttäjä toiselle sivustolle kuin minne hän luulee olevansa menossa.
Tietoturvapäivityksen käytännön toteutus ontuu, sillä kohdatessaan käyttäjätunnuksen ja salasanan sisältävän linkin Internet Explorer antaa lähes täsmälleen saman virheilmoituksen kuin siinä tapauksessa, että tavoiteltuun verkkopalveluun ei saada yhteyttä. Päivityksestä aiheutuvista ongelmista huolimatta Microsoft suosittelee Windows-käyttäjille kriittiseksi luokitellun päivityksen asentamista välittömästi.
URL-käyttäjätunnistus on jo vuosia ollut osa HTTP-standardia, joskin sen tukeminen on jätetty valinnaiseksi. Nähtäväksi jää, onko Microsoftin tekemällä linjauksella vaikutusta URL-autentikointia tukevien Opera-, Mozilla- ja Safari-selaimien kehitykseen.
oma, 10.2.2004 00:05. Lähde: Sektori
Muita aiheeseen liittyviä uutisia
Anonyymi kommentoija, 10.2.2004 01:10:20
Anonyymi kommentoija, 10.2.2004 01:49:32
scheme://extradata@hostname/polku
Näin tiivistäen.
Se mikä tässä on hyväksytty käytäntö on BASIC-autentikointitavan (WWW-Authenticate: Basic) käyttäjätunnuksen ja salasanan antaminen extradatana. Selainhan ei tuota urlia lähetä palvelimelle vaan tulkkaa sen itse, palvelin näkee vain että selain tahtoo /blaablaa/blaa:n ja antoi usernamen foo ja salasanan bar, palvelimen hostnameksi selain luulee piupauta.
Masa, 10.2.2004 09:43:53
RFC-dokumentissa 1738 mainitaan ensin yleinen URL:n muoto kuten oletkin sen jo esittänyt, mutta HTTP:n tapauksessa erityisesti mainitaan näin:
"An HTTP URL takes the form: 'http://<host>:<port>/<path>?<...'"
ja pari riviä alempana: "No user name or password is allowed."
Sen sijaan FTP:n URL-määritelmässä mainitaan, että FTP-URL:iin voidaan sisällyttää joko käyttäjätunnus, salasana, molemmat tai ei kumpakaan.
Lisää tietoja Internet-standardointiprosessista ja RFC:istä voi käydä lukemassa osoitteesta http://www.ietf.org/ .
weicco, 10.2.2004 11:38:24
http://www.ietf.org/rfc/rfc2396.txt
3.2.2. Server-based Naming Authority
URL schemes that involve the direct use of an IP-based protocol to a specified server on the internet use a common syntax for the server component of the URI's scheme-specific data:
<userinfo>@<host>:<port>
where <userinfo> may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the server. The parts "<userinfo>@" and ":<port>"mmay be omitted.
server = [ [ userinfo "@" ] hostport ]
The user information, if present, is followed by a commercial at-sign "@".
userinfo = *( unreserved | escaped |
";" | ":" | "&" | "=" | "+" | "$" | "," )
Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used.
Masa, 10.2.2004 11:59:52
Anonyymi kommentoija, 10.2.2004 20:08:56
Nonsense, 10.2.2004 08:00:23
Ensin MS ilmoittaa päivityksen tulevan joskus vasta myöhemmin kuin se nyt julkaistiin. Se julkaistiin kuitenkin "ajoissa" eli vain pari kuukautta aukon löytymisestä. No, nyt sitten kuitenkin todetaan että tämä vihdoinkin (kuitenkin "etuajassa", jos MS:n aikatauluun verrataan) saatu pätsi onkin tällainen "ai siinä on vikaa, no poistetaan koko ominaisuus"-räpellys, johon ei ole vaivauduttu edes tekemään kunnollista "virhe"ilmoitusta (tuollaisen url-autentikoinnin käyttäminenhän ei ole mikään oikea tekninen virhe, vaikka tietysti sen järkevyys voidaan usein kyseenalaistaa).
Ja itse url-autentikoinnista olen sitä mieltä että se on aivan perustoiminnallisuus selaimessa, ja lähinnä sitä käytetään (ja ehdottomasti kannattaa käyttää vain) avoimissa palveluissa, joissa ei syystä tai toisesta kuitenkaan käytetä normaalia anonymous-käyttäjää. Esimerkkejähän riittää, esim demo/demo- tai user/user-tunnukset joihin aina välillä törmää.
hanta, 10.2.2004 01:07:56
jos sähköpostin liitteenä tulee viruksia, niin pitääkö outlookista estää sähökpostien lähettäminen ja vastaanotto, vai kannattaisiko vain estää liitteiden automaattinen ajaminen?
entä jos selaimen kotisivun pystyy kaappaamaan aiheuttaen harmia käyttäjälle, niin pitääkö selaimesta positaa oletussivu kokonaan. senhän voi korvata vaikka mainoksilla tai muilla tiedotteilla.
saa nähdä onko kädettömillä päivityksillä vaikutusta muiden selainten suosioon.
hanta
Anonyymi kommentoija, 10.2.2004 19:34:32
hanta, 10.2.2004 21:51:29
hanta
Moby, 10.2.2004 01:36:40
Anonyymi kommentoija, 10.2.2004 04:25:20
ftp:lle mukava tallentaa tuossa muodossa luukut, jotka moisella sisään päästävät. Ftp:llä turha tunnuksia (kuten http:lläkään) yrittää piilottaa koska ne liikkuvat salaamattomina kuitenkin. Yksi copy/paste ja sisään.
sftp testoman@ftp.foonet.fi
sftp:llä et sisään pääse kuin tuollaisella mielestäsi älyttömän vaarallisella urlilla.
Missä se ongelma siis on?
Anonyymi kommentoija, 10.2.2004 07:58:32
sftp testoman@ftp.foonet.fi
sftp:llä et sisään pääse kuin tuollaisella mielestäsi älyttömän vaarallisella urlilla.
Missä se ongelma siis on?
Anonyymi kommentoija, 10.2.2004 08:14:21
- nopea
- helppo
- valmiiksi asennettuna
- tampiokin osaa kun lähettää linkin
//m
Anonyymi kommentoija, 10.2.2004 08:22:53
- helppo
- valmiiksi asennettuna
- tampiokin osaa kun lähettää linkin
//m
// Simo
Anonyymi kommentoija, 10.2.2004 11:53:38
Ihan kaikki eivät siirrä langat punaisina CD-imageita 24/7.
Anonyymi kommentoija, 10.2.2004 08:43:53
Teoriassa, jos henkilö olisi jatkanut IE:llä yritystä, niin olisimme saaneet selaimen latausnopeudeksi ääretön, kun taas ftp-clientilla latausnopeus oli äärellinen. Joten ftp-clientti oli nopeampi.
Anonyymi kommentoija, 10.2.2004 11:45:58
(Ei aivan äärettömiä latausnopeuksia mutta lähelle kuitenkin saa joillain clienteillä kun jatkaa imurointia lähes tiedoston lopusta)
Anonyymi kommentoija, 10.2.2004 20:29:16
En kummiskaan elä maailmassa jossa yksi onnellinen kokemus / onneton kokemus saa minut vielä kallistamaan kuppiani mihinkään suuntaa.
feenix, 10.2.2004 10:10:23
Oikeasti IE:n FTP-klientti toimii osittain ihan hyvin, mutta on siinäkin ikäviä ominaisuuksia, kuten se, ettei se tajua linkkejä ollenkaan. Hakemistot ja tiedostot näkyvät, mutta teepä linkki johonkin hakemistoon niin IE ei näytä sitä ollenkaan. Kiva sitten selitellä ihmisille että hankkivat oikean ohjelman. "Mutkun toimii tää muualla ja ennenkin toiminut ja mitenniintääeiooteidänvika?"
jjx, 10.2.2004 08:27:53
Kyllä se vähän eri asia viuhuuko joku salasana urlissa vai onko se mahdollista saada selville verkkoa sniffaamalla. Useimmilla selaimilla kun on esimerkiksi tapana tallettaa käyttäjän naputtelemia urleja koneen kovalevylle.
Anonyymi kommentoija, 10.2.2004 16:17:53
Yleensä salasanan jälkeen pölähtää joku cookie koneelle. Ei noitakaan pahemmin ole kielletty vaikka sisältävät suuren riskin. Eipä nyt ihan heti tule mieleen sivustoja joille kirjaudutaan .htaccessin kautta.
muutamalle muulle:
tuommoinen ftp-url toimii hyvin farustetuissa ftp-clienteissä + selaimissa.
Anonyymi kommentoija, 10.2.2004 16:20:31
jst, 10.2.2004 16:41:22
------------------
deploy.sh
-------------------
...
compile.sh
wget --quiet --output-document=- 'http://manager:manager@127.0.0.1:666/manager/remov...'
...
hanta, 10.2.2004 16:58:49
www.microsoft.com%01@www.vaarallinensaitti.com
jolloin IE:n osoiterivillä näkyi vain www.microsoft.com.
ongelma ei siis ollut urlissa olevat käyttäjätunnukset, vaan nimenomaan niiden käsitteleminen, jota ei syystä tai toisesta jaksettu korjata. niin, ja minusta esimerkit ovat aivan päteviä, kyseessä oleva ongelma oli IE:n bugi, eikä mitään muuta.
hanta