Domanda per hacker

Provo ad "upparti" questa discussione, io non ne so nulla, anche se secondo me dovresti essere più preciso nella tua richiesta.

L'originale di LMIG
Provo ad "upparti" questa discussione, io non ne so nulla, anche se secondo me dovresti essere più preciso nella tua richiesta.

Gentilissimo grazie, comunque ho fatto un po' di ricerche in rete ed ho scoperto quanto segue...ci sono un sacco di siti che sono facilmente hackerabili (e lo è pure il mio)... praticamente c'è un programma "brute force" (uno dei tanti) che permette di risalire alle password per loggarsi tranquillamente anche in siti a pagamento, ho letto che una buona difesa è quella di allungare le password e mettere sia numeri che lettere e magari anche caratteri speciali (? % $ "/ ) ecc. inoltre un sito dovrebbe chiedere l'inserimento dei "captcha" qualora la password venga digitata per più di 3 volte in modo errato. Questo è tutto quello che ho scoperto, ma sicuramente c'è molto altro ancora. Mi son permesso di chiedere info su strategy perchè ho appurato, leggendo alcuni 3d, che qui ci sono utenti che di informatica ne sanno davvero tanto. Buona giornata a tutti

ciao clapton,
dovresti domandarti se a qualcuno gioverebbero le info sul tuo sito.
se non contiene "informazioni sensibili" ovviamente nessuno tenterà di rubarle, quindi, credo che puoi dormire sonni tranquilli.
per quanto riguarda l'attacco con brute force probabilmente lo intendi mirato a "rubare le credenziali" del log-in dell'account Aruba.
anche in questo caso puoi dormire su 7 guanciali perché il file con le password è ultra criptato con un algoritmo che per essere decifrato un computer normale potrebbe decifrare in qualche migliaio di anni (MD5)!!

Ancora più alte sono le difese per quanto riguarda le poker room perché quell'algoritmo di prima è stato migliorato esponenzialmente e risulta pressoché impossibile per persone comuni con mezzi comuni (anche un mostro di computer con i7 e roba varia è SEMPRE CONSIDERATO SOLO UN COMPUTER NORMALISSIMO)

in più per quanto riguarda le NOSTRE poker room (le .it per intenderci) oltre tutte le misure di sicurezza della piattaforma (di cui ho citato solo il 5%) si è inserita anche AAMS con un processo all'interno del SW client che installiamo sul computer che controlla la regolarità delle partite e delle giocate!!

NOTA. se un hacker ti hackka il computer sul quale hai installato un client di poker può con estrema facilità rubarti le credenziali per accedere e farci ciò che vuole. oppure può semplicemente mandarsi uno "streaming" del tuo desktop e vederti le carte o cose del genere...

MA...

Una persona che sa fare tutto questo non passa il proprio tempo a frodare una poker room e rubare qualche "spicciolo" dai conti degli ignari giocatori..

io dico che ci si può fidare...

se poi parliamo dell'algoritmo "RANDOM" di alcune poker room stiamo qui fino alla notte dei tempi!!

Oddio i modi per attaccare un sito sono potenzialmente infiniti giusto per citarne alcuni: xss injection, sql injection, RFI, LFI ecc. dovremmo sapere in che linguaggio è scritto il tuo sito(html?), se usa un database, ci sono anche codici di javascript? contenuti multimediali vari. Sono moltissime le variabili.
E di certo gli attacchi brute force a quanto ne so sono bloccati dal server oramai in automatico quindi diciamo che non dovrebbero più costituire un problema.

L'originale di Simitch
Oddio i modi per attaccare un sito sono potenzialmente infiniti giusto per citarne alcuni: xss injection, sql injection, RFI, LFI ecc. dovremmo sapere in che linguaggio è scritto il tuo sito(html?), se usa un database, ci sono anche codici di javascript? contenuti multimediali vari. Sono moltissime le variabili.
E di certo gli attacchi brute force a quanto ne so sono bloccati dal server oramai in automatico quindi diciamo che non dovrebbero più costituire un problema.

+1

NOTA. se un hacker ti hackka il computer sul quale hai installato un client di poker può con estrema facilità rubarti le credenziali per accedere e farci ciò che vuole. oppure può semplicemente mandarsi uno "streaming" del tuo desktop e vederti le carte o cose del genere... MA... Una persona che sa fare tutto questo non passa il proprio tempo a frodare una poker room e rubare qualche "spicciolo" dai conti degli ignari giocatori.. io dico che ci si può fidare...

Non è proprio come dici tu..io ho ancora il culo che mi fa male..

L'originale di eujames

se poi parliamo dell'algoritmo "RANDOM" di alcune poker room stiamo qui fino alla notte dei tempi!!

...questo mi inquieta ...

L'ho detto che qui su ps c'è gente super preparata anche in informatica vi ringrazio di cuore per la consulenza. A presto

Ciao, non sono un haker, ma ho preso parte ad alcuni corsi sulla sicurezza informatica (livello base eh, non robe astronomiche!)

Un attacco "brute force" di solito si fa su una password... oramai credo sia limitato ai files zip protetti da password, dato che la maggior parte dei sistemi di login, hanno il blocco utenza dopo una serie di tentativi. (es hotmail, facebook, eccetera)

Per i siti "fatti in casa" gli attacchi più frequenti sono il defacing(cambiare la grafica del sito, solitamente con genitali o minipony) e il denial of service(si scrive così?). Il secondo, se non sbaglio si chiama Ddos, consiste nell'inviare una mole mostruosa di richieste al tuo sito per farlo incriccare. Questi attacchi, spesso, sono fatti per il solo scopo di rompere le palle dato che sono semplicissimi da attuare... in pochissimi casi, sono usati da gente esperta per altri motivi più disastrosi

Per quanto riguarda gli attacchi "monetari" agli account paypal, postepay, carte di credito, poker, diciamo che sono attacchi alla persona. Infatti dato che i sistemi informatici sono evoluti e il livello di sicurezza è abbastanza alto, è diventato più semplice ingannare l'utente per guadagnare l'accesso ad un sistema. Infatti girano moltissime mail del tipo "la tua paypal è stata bloccata, clicca qui per confermare la tua password e ripristinarla"

Basta che 1 su 1000 ci caschi e la cosa diventa molto profittevole.

A volte è ancora più subdola, basta aprire una pagina con un banner per trovarsi dei files che installano programmini che registrano i tasti premuti della tastiera o altre cose così...

Infatti ci sono molti consigli per evitare questi tipi di cose.. ad esempio cancellare sempre i files temporanei di internet (almeno 1 volta al mese), tenere aggioranto il sistema operativo e l'antivirus, non usare outlook express :D, non cliccare i link all'interno della mail quando c'è scritto "clicca qui per fare il login" eccetera eccetera

Per i siti, è meglio farli hostare da chi lo fa per lavoro, perchè soliatamente sa quello che deve essere fatto per garantire un buon livello di sicurezza, che all'utente medio va più che bene... Certo, se sei una banca e devi fare il sito, non vai da aruba, ma vai da un'azienda specializzata che si fa pagare migliaia di euro.

L'originale di urlnotfound

L'originale di Simitch
Oddio i modi per attaccare un sito sono potenzialmente infiniti giusto per citarne alcuni: xss injection, sql injection, RFI, LFI ecc. dovremmo sapere in che linguaggio è scritto il tuo sito(html?), se usa un database, ci sono anche codici di javascript? contenuti multimediali vari. Sono moltissime le variabili.
E di certo gli attacchi brute force a quanto ne so sono bloccati dal server oramai in automatico quindi diciamo che non dovrebbero più costituire un problema.

+1

Sono sia bloccati dai server, sia dai dns che ci sono in internet.
Addirittura, se non erro, se c'è un tentativo di bruteforce, di ddoss o mail spam da un IP, lo greylistano... Se l'IP è recidivo lo blacklistano. La blacklist è usata anche dai DNS, quindi finchè non andrà a rimuovere il proprio indirizzo dalla black list, non potrà manco aprire google
e togliere un ip da una black list è veramente un casino!

Io oltre a ricevere praticamente tutti i giorni e-mail in cui mi informano che ho il conto LIS bloccato, MPS bloccato, postepay (di quelle ho perso il conto), Carta Si, Unicredit ecc ecc, ormai finiscono direttamente nella cartella spam, qualche giorno fa mi è anche arrivata una e-mail da Skrill con la quale mi informavano che qualcuno ha effettuato 3 tentativi di accesso non riusciti nel mio conto e quindi era preferibile cambiare la password ecc. ecc.
Non mi sono preoccupato piu' di tanto, visto che i 285$ incassati con il TAF li ho già ampiamente prelevati e quindi adesso trovano 0, ma all'interno ci sono comunque dei dati sensibili, quindi per sicuirezza un cambio password l'ho fatto. Ma credo che ormai in giro ci sono così tanti truffatori on line, che mi è passata la voglia di utilizzare questi metodi di pagamento, o comunque non lascerò mai somme consistenti, a meno di necessità meglio fare le operazioni veloci e lasciarle vuote.

L'originale di s3nd0h

L'originale di urlnotfound

L'originale di Simitch
Oddio i modi per attaccare un sito sono potenzialmente infiniti giusto per citarne alcuni: xss injection, sql injection, RFI, LFI ecc. dovremmo sapere in che linguaggio è scritto il tuo sito(html?), se usa un database, ci sono anche codici di javascript? contenuti multimediali vari. Sono moltissime le variabili.
E di certo gli attacchi brute force a quanto ne so sono bloccati dal server oramai in automatico quindi diciamo che non dovrebbero più costituire un problema.

+1

Sono sia bloccati dai server, sia dai dns che ci sono in internet.
Addirittura, se non erro, se c'è un tentativo di bruteforce, di ddoss o mail spam da un IP, lo greylistano... Se l'IP è recidivo lo blacklistano. La blacklist è usata anche dai DNS, quindi finchè non andrà a rimuovere il proprio indirizzo dalla black list, non potrà manco aprire google
e togliere un ip da una black list è veramente un casino!

Occhio a parlare di blacklist perché è il modo meno sicuro per proteggere un applicativo web

Per quanto riguarda invece i DOS, questi sono tra le cose più problematiche della rete e non sono così facili da eseguire come sembra (per una serie di ragioni come firewall, negazione delle risorse, ecc...)
Tipicamente oggi non si parla quasi mai di DOS, ma di DDOS, ovvero DOS distribuiti, questo perché un attacco DOS lanciato da una singola macchina (per quanto potente questa possa essere) difficilmente riuscirà a consumare tutte le risorse di un server.

Faccio solo qualche appunto a quanto detto
Gli attacchi che avete accennato (XSS, CSRF, Clickjaking, Injection vari, ecc...) sono attacchi che tipicamente vengono combinati assieme. Ad esempio, difficilmente parleremo di XSS senza parlare di Injection; spesso ho visto fare questa distinzione, ovvero Injection e XSS completamente separati... In realtà l'unico caso in cui l'XSS non ricerca l'Injection e quando si va a fare un'analisi bruta sulle possibili vulnerabilità del sito, parlando quindi di XSS non persistente. Quando si esegue l'attacco vero e proprio, l'XSS è quasi sempre persistente e si parlerà di XSS Injection.

Però fate attenzione perché eseguire un XSS non è così facile come sembra, ma non tanto per i filtri, ma più che altro per i browser stessi!
Non so se avete mai provato ad eseguire uno script in un form di immissione ed a controllare l'error log di un browser... La prima cosa che viene fatta è controllare la politica definita dal SOP (Same Origin Policy), ovvero si controllano nome di dominio, porta e protocollo utilizzato (SOP fa distinzione fra HTTP e HTTPS). Ora, il SOP ormai è stato superato, nel senso che ci sono moltissimi modi per baypassarlo, offuscando il codice. In oltre è limitativo, nel senso che non permette ad HTTP di lanciare cross domain request. Prima del 2009 sono state proposte molte soluzioni al SOP, ma queste hanno aperto buchi nella sicurezza (ad esempio far girare script che non sono sotto il nostro controllo nel nostro stesso dominio SOP con un src...). Nel 2009 con HTML5 è stato introdotto il CORS (Cross Origin Resurce Sharing), che di per se è un enorme passo avanti nella sicurezza web, però non è risolutivo; è stato dimostrato che con una particolare forma di XSS Injection è possibile creare un doppio canale di comunicazione che consente ad un attaccante di vedere il traffico passante tra un client vittima ed un server, sfruttando gli header aggiuntivi introdotti ad HTTP tramite CORS.

Cmq la sicurezza web è un campo molto vasto ed in continua evoluzione, ci vuole molto tempo per capire bene come funziona il tutto
Per testare un applicativo web tipicamente quello che si fa è basarsi su OWASP, la quale organizzazione no profit mette a disposizione un meccanismo attraverso il quale verificare se l'applicativo è "sicuro".
Attenzione però ai filtri: blacklist, whitelist, ecc.. Non sono metodi sicuri per gestire la sicurezza di un applicativo web

wow, quante cose che non so!

Imho, l'ideale se vuoi testare il sito è avere un amico hacker e non cracker (che a dispetto dei primi fa danni..) e chiedere un attacco di test.. un hacker serio ti aiuterà a migliorare la sicurezza e ti dirà dove stanno le falle. Almeno questo io sapevo tra parentesi la vedo l'unica soluzione certa per il tuo problema.

L'originale di ErViolista
Imho, l'ideale se vuoi testare il sito è avere un amico hacker e non cracker (che a dispetto dei primi fa danni..) e chiedere un attacco di test.. un hacker serio ti aiuterà a migliorare la sicurezza e ti dirà dove stanno le falle. Almeno questo io sapevo tra parentesi la vedo l'unica soluzione certa per il tuo problema.

Sicuramente aiuta, ma non basta; il problema principale è che spesso non si pensa a tutte le possibili problematiche

Solitamente quello che si fa è basarsi su questo: https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet

Cmq più che chiedere ad un "hacker", io mi rivolgerei ad un esperto di security che sappia effettivamente come funzionano le web-app

Ad esempio, scommetto che pochissimi sanno che l'unico modo per proteggersi realmente contro l'XSS è applicare le CSP disabilitando lo script inline (obv sarà necessario separare script, da marcatura, da stile) e creare un proprio dominio di sorgenti fidate...

Mi sono perso..

L'originale di ErViolista
Mi sono perso..
In buona sostanza il problema di una web app quando parliamo di XSS è la possibilità di inserire script all'interno dei form che permettono di inserire i dati; se una cosa di questo tipo accade, possono accadere cose disastrose.
Inizialmente per proteggersi da questo problema si sono iniziati ad implementare i famosi filtri (blacklist, whitelist, ecc...). Tipicamente quelli che vengono implementati dagli sviluppatori di web app sono della tipologia blacklist, ovvero tutto ciò che non è esplicitamente negato, è permesso.
Per aumentare il livello di sicurezza si è anche implementato il concetto di SOP (Same Origin Policy), ovvero un meccanismo attraverso il quale il browser impedisce di lanciare script all'interno dell'applicativo, dove lo script non ha stessa origine dell'applicativo stesso (origine definita come tripla: dominio, protocollo, porta). Il problema è che il SOP è facilmente baypassabile, anche perché non può essere troppo restrittivo, altrimenti bloccherebbe completamente il form di immissione dati
In oltre il SOP crea problemi quando si vogliono utilizzare API di fonti esterne (perché appunto vengono bloccate dal concetto di origine). Per sovvenire al problema tipicamente si utilizzava un tag che permetteva alle altre fonti di essere inglobate nella nostra web app: script src="path fonte". Ovviamente chi faceva ciò considerava l'altra fonte fidata... Il casino che è successo con FaceBook un po' di tempo fa ha praticamente creato un buco nella sicurezza di tutto gli applicativi web che facevano uso del suo path (immaginate il casino che è venuto fuori...). Brad Hill del W3C ha sempre scoraggiato la gente dall'inserire i path in quella maniera perché in quel modo la gente non distingueva gli script che FaceBook mandava dal resto. In sostanza tutti mettevano questa cosa nei loro applicativi: script src="connect/facebook.net/en_US/all.js". Questa cosa qua ha creato un buco in qualunque applicativo ne facesse utilizzo...
Ad oggi il metodo corretto per inglobare altre API è il CORS (Cross Origin Resurce Sharing)
Per quanto riguarda i filtri, il problema principale è che questo tipo di misure di sicurezza tentano di simulare il comportamento del browser (lato client) in un ambiente server; cit. "browser diversi si comportano in maniera diversa".
Il problema è che il modo con cui i parser di tali applicativi sono costruiti è segreto, e appunto cambia da browser a browser. Se iniziamo a giocare con meccanismi di offuscamento dei tag, i filtri vengono baypassati (perché non rilevano problemi in ciò che inseriamo), ciò che abbiamo inserito passa al browser, lo parsifica, ciò che abbiamo inserito in maniera offuscata viene interpretato in maniera particolare dal browser stesso e l'XSS viene applicato

Per risolvere il problema, di recente (3 o 4 anni credo) si è iniziato a parlare di CSP (content security policy). In buona sostanza si inseriscono delle politiche di controllo dell'accesso. Ad esempio dico che per me può accedere al mio applicativo un script che proviene da tale fonte, oppure regole di accesso sugli stili, ecc...
Obv questo da solo non basta a risolvere il problema perché possiamo anche qua baypassare offuscando. Soluzione: disabilitiamo la possibilità di eseguire codice dall'applicativo stesso (ovvero tutto ciò che è inline). Obv questo blocca anche i nostri di script inline, quindi dobbiamo separare marcatura da script, ovvero avere un file js separato e all'interno dell'applicativo inserirlo come dominio affidabile, ovvero scrivere qualcosa del tipo: Content-Security-Policy: default-src 'none'; script-src 'miei_script.js' (ed è qua che veramente si vede la differenza tra pensare ad una buona costruzione architetturale dell'applicazione, separandone i contenuti, a scrivere qualcosa inline...)

Marò che casino.. e visto così non ce ne sortiranno mai.. è un mondo in evoluzione che mi lascia di stucco.. sembra quasi un ecosistema a parte (e sono senza metafora.. U.U )