Oggettivamente e’ anche vero che mi capita raramente di usarli, penso negli ultimi 2 anni ho avuto un solo use case dove aveva senso usarlo piuttosto che costruire un integrazione in altri modi via API o shared components
penso sia un trend un po ovunque, stanno scomparendo perche’ di fatto hanno pochi utilizzi validi e venivano abusati con situazioni appunto dove si manda roba avanti e indietro senza sicurezza
Ho un’esperienza opposta, stanno scomparendo i widget creati caricando un js dall’esterno e stanno virando tutti su iframes
Guarda ti faccio un esempio di iframe terribbbile che vedo quotidianamente.
I siti dei supermercati (tesco, asda, sainsbury, etc) che quando vai al pagamento ti aprono un iframe dentro al loro sito.
Perche’. PERCHE’ cazzo, invece di farmi un redirect diretto sul sito della provider finanziario che usi per accettare il pagamento. Basta un niente (per uno che sa quel che fa) a fare injecting in quell’iframe di un altro sito di pagamento.
Hai mai visto un iframe che carica paypal?
Se fai pagare via paypal ti apre un link con un handshake a monte che fa si che paypal sappia che tu sei tu (venditore) e fa fare login all’utente paypal e prima di pagare ricapitola tutti i dati forniti del venditore (nome, indirizzo, etc etc)
Eppure non mi pare paypal sia sull’orlo del fallimento, anche se non permettono di usare iframe per farsi pagare tramite loro.
Sul discorso comodita’, e’ appunto tutto la’. E’ comodo e non vuol dire essere vulnerabile in automatico ma diffondere l’uso di iframe va capito anche che normalizza nell’utente “vederlo succedere” e abbassare la guardia.
Certo, all’azienda che un tizio si prenda l’inculata perche’ paga una scammata frega cazzi, io sto ragionandone in ottica di protezione dell’utente.
heads up… visto che me l’hanno chiesto in molti di recente, ho messo su un nuovo blog cosi’ condivido informazioni con piu’ persone 
Quindi penso che scrivero’ li’ invece che in questo thread cosi’ non devo scrivere in italiano 
Se vi va potete fare subscription cosi’ avete notifiche quando pubblico qualcosa. :)
Dimenticavo il link 
ma no che scrivi sul blog, scrivi qua che la gente può discutere, un blog è a senso unico
400 di solito significa che c’e’ qualche errore nei parametri/request body, o content type sbagliato etc. Puoi condividere piu’ dettagli?
Può sempre scrivere sul blog e postare qua il link quando scrive qualcosa di nuovo
Certo :)
Non so se e’ esattamente la situazione che ho in mente perche’ non compro da quei siti pero’ tecnicamente l’uso di iframe e’ praticamente un obbligo per essere PCI compliant perche’ usando l’iframe e’ il tuo payment processor che deve essere compliant e non tu possessore del sito.
https://docs.stripe.com/security/guide?locale=en-GB#pci-compliance-requirement-by-integration
Spesso non ci si rende conto ma anche solo l’embed di stripe dei soli campi della carta di credito che possono apparire come normalissimi text input field all’interno della pagina di checkout, sono di fatto degli iframe.
Questi iframe sono uno standard da 10+ anni e sono ovviamente totalmente isolati, non mi risulta ci siano mai stati casi dove questa tecnologia e’ stata bucata.
Stasera ho iniziato a preparare un post con una introduzione su come faccio recon quando inizio a lavorare su un nuovo bounty program. Mettero’ il link qui quando e’ pubblicato o se volete potete fare subscribe sul blog per ricevere notifiche.
Mi piacerebbe scrivere una serie di posts per beginners principalmente. Ho gia’ qualche altro post in mente dopo recon come content discovery, altre cose di osint e poi tips & tricks per trovare e fare exploit di molte vulnerabilita’.
Quali altri argomenti pensate che e’ buono pubblicare per chi vuole iniziare con bug bounties o security in general?
Scusa non avevo visto questo reply. Per me e’ piu’ semplice e veloce scrivere in inglese e poi con un blog pubblico molte piu’ persone possono leggere che non capiscono l’italiano e/o non sanno di questo forum.
Possiamo pero’ discutere qui sul contenuto dei post, e posso rispondere domande etc :)
Quali e dove trovare i materiali per “iniziare”.
Che background hai tu e cosa pensi sia stato utile dal tuo background e cosa invece ti sia mancato (se c’e’).
In generale, quali sono le cose piu’ semplici da cui partire (come conoscenze) per poter partire con robe semplici nel security/bug discovery
Note taken, thx :)
Si questo è interessante.
Alcune domande a caso che mi vengono in mente:
Cosa controlli prima di cominciare a testare? (Cerchi di capire che tecnologia hanno usato? Eventuali sottodomini? Cosa succede quando disabiliti JavaScript? …)
Parti da qualche funzionalità in particolare, perché magari ha più probabilità di essere rotta? (Login, upload file? …)
Tools da usare assolutamente ?
Cosa non fare o errori comuni per non perdere tempo?
Provero’ a rispondere a tutte queste domande in dettaglio nei post che ho in mente di scrivere
La versione TL;DR e’ che se lo scope e’ piccolo, e.g. senza wildcard domains, allora inizio a dare una occhiata alla main app direttamente. Se invece lo scope e’ grande e ci sono anche wildcard domains, avvio recon per scoprire prima tutti i subdomain e domini correlati e cmq in scope, filtro quelli che sono “alive” (cioe’ rispondono a web requests), e genero screenshots automaticamente per tutti i siti che rimangono insieme ad altre informazioni (headers etc). Se lo scope e’ grande ci possono essere centinaia o piu’ hosts da controllare, e con una gallery di screenshots e’ piu’ veloce vedere se ci sono hosts che sembrano interessanti e che dovrei controllare prima di guardare alla main app.
La seconda fase della recon e’ per vedere il tech stack e fare content discovery, per trovare endpoints per esempio non documentati che potrebbero essere vulnerabili. Per questo faccio anche una ricerca su risorse come WayBackMachine, perche’ spesso vecchi endpoints ancora presenti ma non piu’ in uso possono essere vulnerabili.
Di solito scelgo un target in base alla quantita’ di funzionalita’ che e’ probabile che ha. E di solito preferisco target B2B perche’ di solito hanno diversi ruoli, permissins etc che sono spesso fonti di vulnerabilita’.
Come tools ce ne sono tanti e ho pure creato la mia automation per parecchie cose. Per esempio ho automatizzato tutta la recon con una Rails app e background workers su Kubernetes con autoscaling, cosi’ posso fare eseguire molti jobs in parallelo senza preoccuparmi di quanti server servono etc. In questo modo, quando ho un nuovo target, aggiungo i domini e la mia automation fa il resto, notificandomi su Slack se ci sono nuovi hosts che vale la pena controllare. Per esempio uso un trucco monitorando la cerificate transparency cosi’ quando un certificato viene provisionato per un nuovo hostname, ho una notifca immediata, cosi’ sono tra i primi a saperlo. La maggior parte degli altri hackers usa tools per enumerazione di subdomains che dipende da varie cose e c’e’ sempre un delay fino a quando rilevano un nuovo host.
Nella series che voglio scrivere non ho intenzione di condividere la mia automation (forse la rendo open source in futuro, ci devo pensare) pero’ descrivero’ come fare le stesse cose manualmente.
Side question: Hai un kubernetes su bare metal mi pare di capire. Che spec hw hai messo su? E’ una cosa che vorrei fare anche io ora che ho preso casa e non devo preoccuparmi di traslochi per landlord pazzerelli e non ho mai guardato a fondo questo aspetto dato che k8s lo uso si ma sempre via cloud providers
mi spieghi un attimo meglio?
Intendi dire quando un certificato scade e viene sostituito? O ho capito male?
e cosa comporta questo?
Oppure che hanno aggiunto un sottodominio a un certificato e quindi scopri che c’è… non ti seguo.
Uso Hetzner Cloud con k3s, perche’ cosi’ posso usare il Cloud Controller Manager di Hetzner e avere autoscaling facile
Ogni volta che un certificato viene provisionato, esso viene aggiunto a public logs e puoi fare query con un operator come google or crt.sh.
Il vantaggio e’ che se monitori in questo modo, hai una notifica immediata quando un nuovo host diventa alive per un target program, in confronto al tempo che ci vuole fino a quando questi nuovi hosts vengono trovati con tools come amass, subfinder etc.