Newsgroup: it.lavoro.professioni.webmaster
Titolo: Alla faccia del segreto bancario svizzero!

Questo form di contatto
http://www.bancastato.ch/index/formulario.htm?id=622&curr=3505
della banca svizzera Banca Stato, banca dello stato del Cantone Ticino, 
invia il testo del messaggio !!!IN GET!!!
Che schifo!
E tra l'altro il form genera anche errore e non viene inviato!
Una banca che si fa fare il sitarello da suo cuggino! Che pena!

 invia il testo del messaggio !!!IN GET!!!
E' un form di contatto generico, non per transazioni valutarie.
Non è che siccome sono un banca, mettono la combinazione pure alla porta del 
cesso...
GB 

 cesso...
Un webmaster che passa un testo in get E' UN IDIOTA.
Assunto questo, a maggior ragione lo è per un form di contatto DI UNA 
BANCA la quale necessita di livelli di sicurezza, commisurati alla 
singola situazione, ma sempre impeccabili e quantomeno ad un livello 
media per la situazione.
Passare variabili in get NON E' NELLA MEDIA neanche di una maschera di 
login di una casella di posta gratuita, figuriamoci se può essere 
accettabile per domande ad una banca che per quanto a livello 
commerciale possono chiaramente contenere elementi molto personali e 
sensibili.
Se ancora non ci arrivi, dopo aver impostato opportuna segretissima 
combinazione 12345 al tuo cesso, tira la catena e fai buon viaggio.

 combinazione 12345 al tuo cesso, tira la catena e fai buon viaggio.
Si, vabbč....rilassati che poi ne riparliamo con calma.

 invia il testo del messaggio !!!IN GET!!!
Io questo accanimento con GET non lo condivido, a parte la dimensione 
dei parametri GET o POST è uguale, si leggono identici.

 Tipo questo qui: 
www.google.com
Un campo input e un campo textarea NON SOLO LA STESSA COSA! Se non sai 
un cazzo taci!
Inoltre non conosci le questioni tecniche che stanno dietro la scelta 
del passaggio in get del campo di ricerca, per cui taci due volte.

 dei parametri GET o POST è uguale, si leggono identici.
Palle! I get vengono loggati dal browser e possono essere loggati dai 
proxy che attraversa. I post no!

Fester ha scritto:

Si hai ragione. I dati delle chiamate post non vengono passati nel body 
della richiesta, bensì vengono trasmessi telepaticamente dal criceto che 
sta nel server all'utente che sta richiedendo la pagina.
Ma mi facci il piacere!!! :-)
Bye!

Generale Cluster ha scritto:

ehm... scambiare le posizioni di "criceto che sta nel server" e "utente 


 proxy che attraversa. I post no!
E dove l'hai letto? Su hackerjournal ? :)
-- 
  Pierquinto Manco
  Docebo Staff
 
http://www.docebo.org
 
http://www.docebo.com

 E dove l'hai letto? Su hackerjournal ? :)
... macchè ha fatto un corso alla Scuola Radio Elettra 

 Si hai ragione. I dati delle chiamate post non vengono passati nel body 
Ripeto: I get vengono loggati dal browser e possono essere loggati dai 
proxy che attraversa. I post non vengono loggati dal browser e 
normalmente non vengono loggati dai proxy che ad un primo livello di log 
loggano solo gli uri.

 proxy che attraversa. I post no!
Possono essere loggati eccome. 
Perché dici di no?

 del passaggio in get del campo di ricerca, per cui taci due volte.
Si, certo, č proprio cosě.
Ripassa il concetto di https e domandati perchč quel form lě č in http 
mentre l'home banking no.
Detto ciň, vai bello...sei troppo idiota, impreparato, saccente ed 
irascibile per aspirare ad essere un mio interlocutore.

Fester ha scritto:

ok, così è corretto :-)

 Perché dici di no?
Dico che normalmente non lo sono. Un proxy su una rete locale ad esempio 
normalmente può essere configurato per filtrare l'accesso ai contenuti e 
loggare gli uri i quali contengono le informazioni passate via get 
mentre le informazioni passate in post non vengono loggate.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ti riordino un attimo le cose (non è polemica, in parte è quello che hai
detto, ma un attimino chiarito).
Prima di tutto bisogna distinguere qual'è un comportamento "normale" e
quale non lo è. Nella normalità browser e proxy loggano solo gli URI.
Questo non significa *assolutamente* che non possano loggare anche le
intestazioni, anzi...
Poi passiamo alla seconda distinzione: il lato client e il lato server.
Sul lato client c'è il browser. Che è controllato dall'utente. E che
viene configurato dall'utente.
Il browser, con o senza cifratura, può loggare _tutto_. Sta all'utente
decidere cosa loggare. E se non vuole loggare gli URI, può benissimo
farlo. Quindi il browser, con il problema originale (la sicurezza del
metodo GET) non c'entra nulla. Il metodo GET è sicuro lato client.
Lato server possono esserci proxy. Un proxy, a meno che l'admin non sia
folle, non logga il contenuto delle richieste. E quindi qui il metodo
GET è meno sicuro di quello get. Ma non mi sembra un grossissimo
problema nel form proposto...
Poi ci sono anche le questioni tecniche. Il GET permette di infilare
meno roba del metodo POST. E questo lo rende sconsigliabile con le
textarea, è indubbiamente vero. Ma non è un problema di sicurezza.
- --
Lorenzo Breda - Linux User #387700
Query 
keyserver.linux.it
 for GPG pub key ID: 0xF50D4C69
Fingerprint:
3618 E21C CA59 0EAC 2E00 F9BF 34A4 D6A0 F50D 4C69
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGOM4wNKTWoPUNTGkRAur4AJsHtAQ/Jqo+RzgfMdZrShx0dskjNwCfTroK
xnyA8DAt6aWcA87jWOerJDM=
=fVSa
-----END PGP SIGNATURE-----