Una cosa sottovalutata ma che risulta vettore di molte fantasiose possibilità di attacco sono i form di joomla .. finora tutte le versioni che ho visto.
Usiamo come esempio il form contatti.
Anche se non attivato è sempre e comunque raggiungibile al suo uri standard, ma esiste un problemuccio puntandolo direttamente... che ha bisogno di un id, ovvero un contatto a cui scrivere, non si può entrare nel default se disattivato perchè riceverete un errore... non è attivato...
Così bisognerà arrivarci con un po' di tentativi incrementando l'id finchè non apparirà il form
/index.php?option=com_contact&view=contact&
id=1&tmpl=component
...ora... questo è il segreto di pulcinella... visto lo spam che arriva... potete aver nascosto gli indirizzi email ma cosa succede se vi inviate una copia del messaggio? Probabilmente riceverete una mail da una mail valida utilizzabile per lo spam.
Ma non è tutto quì, innanzitutto la validazione dei campi è js, quindi portando fuori quel form questa viene inibita.
L'unico controllo (inutile) è quello che si trova quì:
components/com_contact/controller.php riga 118 circa
// Check for request forgeries
JRequest::checkToken() or jexit( 'Invalid Token' );
... na cippa!
poichè presuppone che stai attaccando alla c.d.c. quel form, invece basta una chiamata e due regex per avere un token valido che mi permette di skippare quel controllo.
Ma non è ancora tutto quì...
Nonostante questa cosa sia abbastanza abusiva bisogna pur sempre passare dal form per avere il token!
Eh si... se si considera un attacco a manina si ma se consideri un attacco con uno script ti parte un treno di messaggi in 0 secondi...
Il token resta "vivo" per la urata della sessione ed è lì che si trova... il principio di controllo è:
la sessione conserva il token, ogni pagina che ne ha bisogno lo chiede e viene preso dalla sessione, la pagina viene spedita e all'arrivo viene nuovamente chiesto per verificare se è uguale.
Quindi posso portarmi fuori il form e abusare tranquillamente di quel token poichè ha un flag "forceNew" che di default è settato a false.
Una cosa che già può impedire attacchi a raffica potrebbe essere di forzare il rinnovo di quel token, quindi già dopo il check posso fare una cosa del genere
$session =& JFactory::getSession();
$session->getToken(true); // il true è il flag forceNew che forza la creazione di un nuovo token
Un'altra cosa utile sarebbe avere una "memoria" degli invii per la sessione, come si vede in molti form per controllare se dopo poco ne invii un altro...
...altri suggerimenti? ... non dite captcha
...
M.
AVVISO AI NAVIGANTIQuesto post non ha lo scopo di incoraggiare l'abuso che rimane un REATO e come tale viene perseguito.
