Newsgroup: it.comp.java
Titolo: questione di sicurezza Form in Struts

salve a tutti
il discorso che sto per fare è un po' lungo, ma vi prego di avere pazienza
perchè credo che potrebbe essere una discussione interessante...
Allora utilizzando form con scope session (ormai ho rinunciato a quelle in
request perchè mi danno problemi... cmq mi piacerebbe approfondire anche
questo aspetto!!!) come trasportate le informazioni che vi servono in
presentazione ma che non saranno campi editabili??
Cerco di fare un esempio:
Campi editabili: Descrizione, Prezzo
Altri valori da mostare: Codice (NB chiave primaria sul DB)
Immaginando una situazione in cui venga chiamata la funzionalità "modifica
scheda articolo" di un certo articolo, la jsp di edit dovrà contenere le 2
textbox
per Descrizione, Prezzo, in più dovrò visualizzare solo come testo il Codice
(per ricordare all'utente cosa sta modificando).
Per fare questo la mia idea fino ad oggi è sempre stata:
1) creo la formArticolo  con i set/get di TUTTI e 3 i campi: Codice,
Descrizione, Prezzo.
2) prima di chiamare la jsp che riferisce la formArticolo con i tag di
struts, la popolo con i dati provenienti dal DB (popolo tutti e 3 i campi).
3) mostro la jsp dove verranno cambiati i dati (Descrizione e Prezzo) e dove
come titolo avrò il Codice in sola visualizzazione.
4) Alla pressione del submit la mia action Save riceverà la formArticolo
opportunamente modificata per i campi Descrizione, Prezzo ed essendo
    in scope session ritroverò lo stesso Codice che avevo popolato al punto
2.
IN quest'ultimo punto (ipotizzo l'utilizzo di JDBC puro senza Hibernate o
simili) faccio un PreparedStatement di questo tipo:
UPDATE Articoli SET Descrizione = ?, Prezzo = ? WHERE Codice = ?
andando a settare i vari parametri con i dati della formArticolo così:
- prepstat.setString( 1, form.getDescrizione() );
- prepstat.setDouble( 2, form.getPrezzo() );
- prepstat.setString( 3, form.getCodice() );
e tutto funziona! (spero abbiate avuto la pazienza di seguirmi fin qui)
Ecco la domanda: che succede se qualcuno mi fa un "injection" nei dati in
post inviandomi un parametro Codice con valore arbitrario?
IL meccanismo di struts vedendo arrivare tale parametro proverà ad invocare
il set opportuno e se il nome è corretto mi verrà sovrascritto
il valore di COdice che avevo popolato e che mi tenevo gelosamente in
session (rivedi punto 4 eventualmente)
In definitiva il record modificato potrebbe essere tutt'altro rispetto a
quello scelto applicativamente e su cui si era aperta la pagina di
editing...
Ecco allora che ritorniamo alla domanda inziale (come trasportate le
informazioni che vi servono in presentazione ma che non saranno campi
editabili??)
Una soluzione potrebbe essere mettere in sessione come attributi separati le
varie informazioni che dovranno essere usate solo come visualizzazione,
però lo trovo scomodo, c'è gia la form che funge da contenitore comodo,
perchè sparpagliare le informazioni dentro la session costringendomi ad
inventarmi nomi che sicuramente non ricorderò (o sbaglierò) quando andrò a
ripescarli dalla jsp? (inoltre con tanti attributi relativi alle numerose
form che uno può avere va a finire che non si riesce a fare una buona
pulizia e la sessione rimane piena di valori inutili)
Un'altra soluzione potrebbe essere trasportare le informazioni per la sola
visualizzazione dentro la formArticolo però casomai cambiando la firma
per il codice:
invece del solito getCodice() e setCodice() che soffrono del problema
esposto prima...
fare una cosa del tipo mygetCodice() e mysetCodice() scongiurando la
possibilità di injecton, visto che il sistema del bean "lavora" solo con
firme di metodi che iniziano con get/set, però in questo modo mi perdo la
possibilita nella jsp di accedere a queste info mediante i tag, sono
costretto
a prendermi la form dalla sessione e invocare i metodi a mano cosi:
<%=formArticolo.mygetCodice()%>
Ma allora una soluzione senza problemi c'è??
Grazie per avermi seguito fin qui, spero diventi una discussione utile per
tutti...

Non uso Struts da un bel po' ormai, ma posso dirti che meccanismo usa
Spring MVC; d'altronde Struts 2 (uscito da poco) dovrebbe essere una
miglioria anche in questo senso.
In Spring MVC dicevo puoi dire alla classe DataBinder quali campi
accettare per il binding da parametri HTTP a form/bean, immagino che
anche Struts ormai abbia qualcosa di simile.
--
www.megadix.it


umh bello, cosi la firma dei metodi è ok per i javabean, ma se il campo non
è bindato da codice java, non lo si può attivare semplicemente
indovinando il nome del parametro...
però io uso Struts 1.3.8 .... aiuuuuuuuto!
A parte scherzi grazie della risposta, se non altro quando passerò ad un
framework più moderno troverò il problema già risolto....
Nel frattempo c'è qualche tapino che si è imbattuto nel mio stesso problema
in Struts 1.x??
ciao

non c'è proprio nessuno con lo stesso problema???



Ti ri-rispondo io, che ho avuto sì lo stesso problema :)
Gli approcci sono diversi e dipendono anche da chi dovrà mettere mano
al tuo codice; in genere ho visto che i "novizi" anche se c'è da
scrivere molto e ripetitivo non se la menano...
= Approccio #1 =
L'ActionForm (o chi per esso) ha:
- un'istanza di JavaBean con le stesse proprietà o un mapping di esse;
- una proprietà "context" da impostare prima della fase di binding
http per stabilire quali proprietà accettare con i metodi setXXX().
Esempio:
- context = "description" : consente di modificare solo name e
description;
- context = "data" : modifica di prezzo, qta, ecc.
Se non sbaglio la validate() viene chiamata dopo il binding, e lì
decidi cosa "passare al tuo bean".
= Approccio #2 =
Ricrei artificialmente il meccanismo di Spring...che daltr'onde
sfrutta le specifiche JavaBean e i property editor, insomma non è che
ha inventato nulla, eh!
Il primo approccio ovviamente è il più semplice da capire ma richiede
molto codice: come devi duplicare le property degli oggetti su cui
lavori.