Back to top

Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - devil_cp

Pagine: [1] 2 3 4 ... 6
1
Ciao a tutti,

Finalmente siamo operativi!

Se qualcuno è interessato mi contatti in privato.

2
Siamo un'azienda  IT e stiamo cercando collaboratori per la realizzazione di siti ed estensioni insieme al notro team di sviluppo interno.

E' preferibile che il candiodato sia in zona.

Riferimento
Pietro Capurro

Azienda
FOS S.r.l.
Via Milano 166 N/r
16126 Genova
Tel.  0104076998
P.IVA IT 12851070156

3
Sicurezza / Re:Area riservata clienti studio commerciale
« il: 04 Giu 2013, 10:09:06 »
Ho condiviso solo un'esperienza lavorativa.

Grazie

4
Sicurezza / Re:Area riservata clienti studio commerciale
« il: 03 Giu 2013, 21:43:44 »
Ciao baronepiovasco,

Cerco di darti qualche dritta in più punto per punto.

Premetto che il rispetto delle norme per il trattamento dei dati richiedono attenzione all'intero sistema e non solo al software che ci gira e alle procedure di gestione dello stesso. Pertanto spesso è necessario documentarsi bene in materia o avvalersi dell'esperienza di qualcuno chesappia come muoversi.

Pertanto ripropongo i primi due suggerimenti di carattere generale:
Citazione
Le regole da seguire sono parecchie e per questo ti ci vuole un buon consulente.

Sicuramente il buon punto di partenza è un server dedicato, anche virtuale. Poi Buona gestione dei backup e della sicurezza all'accesso fisico e logico al server.

Proseguo aggiungendo qualche dritta punto per punto:

Citazione
Non intellegibilità del database: non deve essere possibile con un semplice accesso alla base dati capire le associazioni tra i dati sensibili e il loro proprietario. In questo caso si possono adottare metodi di criptazione per cifrare parte o l'intero database.

In questo caso abbiamo modificato la normali classi di accesso al database di joomla per far sì che i dati sanitari non siano facilmente riconducibili ai rispettivi proprietari con un accesso diretto alla base dati. In particolare si è cercato di fare in modo che i dati siano criptati in maniera non univoca, pertanto lo stesso dato di partenza può dare origine a dati codificati estrememente diversi.


Citazione
Tracciare con dei log tutti gli interventi da parte dei diversi utenti che possono alterare i dati sensibili. Questi log poi devono essere custoditi in un luogo dove non siano alterabili. Ad esempio sullo stesso server dell'applicazione l'amministratore del server li potrebbe alterare.

Abbiamo creato appositi file di log per tracciare quanto richiesto utilizzando quanto offerto da Joomla. Poi abbiamo attivato diverse procedure per criptare, trasferire, rendere non alterabili e accessibili solo a chi di dovere i log.


Citazione
Nell'applicazione i dati sensibili non devono mai apparire nella stessa schermata con i dati del loro proprietario.

La soluzione più semplice è stata quella di usere la tipica visualizzazione a schede in maniera tale da non far stare nella stessa scheda informazioni che associno al proprietario i rispettivi dati sensibili. Evitando così attacchi di tipo shoulder surfing.


Citazione
I dati devono essere acceduti esclusivamente dagli utenti che ne hanno diritto.

Abbiamo fatto un buon utilizzo delle ACL di Joomla ed aggiunto tutti i controlli necessari ad evitare che un utente possa accedere ai non di sua competenza.


Citazione
Durante il tragitto dal server al client i dati devono essere criptati. In questo caso viene bene l'utilizzo del protocollo https con un certificato ssl

Quì non ho altro da aggiungere.


Citazione
Accesso in sessione unica da parte degli utenti

Non possono esserci due autenticazioni contemporanee per lo stesso utente Joomla. Abbiamo trovato un apposito componente.


Citazione
Opportuna gestione delle passwordProbabilmente nel tuo caso non necessiti di tutti questi accorgimenti, ma spero ti possano essere di aiuto.

Abbiamo utilizzato alcune componenti che garantiscono una più alta complessità della password, il cambio della password secondo determinati criteri temporali e la gestione dello storico delle  password, così gli utenti non possono utilizzare sempre la stessa password.

Spero di averti dato qualche spunto in più.

5
Sicurezza / Re:Tabella users compromessa
« il: 07 Apr 2013, 09:45:13 »
Ti interessa lo script che hanno utilizzato? Dovrei averne una copia o parte di esso.

6
Sicurezza / Re:Tabella users compromessa
« il: 07 Apr 2013, 09:15:33 »
Avevi attivato la funzionalità per l'inserimento dei commenti? Se sì era attiva con la richiesta di inserimento di capcha?


Se non c'era il capcha potresti aver subito un attacco nel quale uno script malevolo è stato postato come commento e sfruttando punti deboli del codice è stato eseguito.


Prova inoltre a vedere se nei log trovi qualcosa.

8
Sicurezza / Re:Tabella users compromessa
« il: 06 Apr 2013, 14:13:09 »
Sì, probabilmente è uno script che hanno usato anche con il mio sito un po di tempo fa.

Quì puoi trovare il relativo post: http://forum.joomla.it/index.php/topic,185555.0.html

9
Database / Re:Errore nell' importo del file .sql in MAMP
« il: 06 Apr 2013, 14:10:57 »
Se ha importato correttamente i dati e tutto funziona non serve.

10
Database / Re:Errore nell' importo del file .sql in MAMP
« il: 06 Apr 2013, 13:57:49 »
Sulla macchina dove vuoi modificare il tuo sito crea un nuovo db vuoto con lo stesso nome.

Poi aggiungendo il comando use in testa al tuo file SQL riesegui l'importazione per popolare il db.

PS: quando fai l'export del contenuto di un database di default non ci sono le istruzioni di creazione del db.

11
Database / Re:Errore nell' importo del file .sql in MAMP
« il: 06 Apr 2013, 13:40:28 »
crea il db pippo -> in testa al file sql metti: use 'pippo';

tutto con notepad++ o editor utf8
attenzione che le virgolette non sono gli apici come ho messo, copia una stringa già virgolettata dal file per averle..

EDIT .. ops .. scusa devil ma nn ho letto il tuo post prima di scrivere

Non ti preoccupare, la tua risposta non può che avvalorare la mia.  :P

12
Database / Re:Errore nell' importo del file .sql in MAMP
« il: 06 Apr 2013, 13:18:20 »
Hai già creato il database vuoto dove importare?

Se sì aggiungi prima dell'istruzione di drop visualizzata nell'errore l'istruzione: use <nome database>;

Prova a reimportare.

13
Se la differenza ė tra Windows e Linux una delle prime cose che mi viene in mente sono i nomi dei file maiuscoli o minuscoli ad esempio: in genere Linux è case sensitive mentre Windows no.

14
Sviluppo / Re:Chained Select
« il: 04 Apr 2013, 12:05:16 »
Chi cerca trova.

Prova a leggere questo: http://forum.joomla.org/viewtopic.php?t=771082

15
Credo che tu debba accertarti dei limiti sul numero di mail che possono essere inviate (es giornalmente).


La procedura di trasferimento del dominio da un hoster ad un altro spesso è gestita dall'hoster di destinazione. Ovviamente devi pianificare bene le cose e mettere in conto che potresti rimanere irraggiungibile per un po' di tempo.

16
Sviluppo / Re:Ricerca oggetto tramite popup
« il: 23 Mar 2013, 20:22:59 »
Ti ho segnalato il field user perché anch'io sono partito da quello per poi sviluppare quelli personalizzati analoghi.

17
Sviluppo / Re:Ricerca oggetto tramite popup
« il: 22 Mar 2013, 14:18:44 »
Prova ad aggiungere il seguente field al tuo form: http://docs.joomla.org/User_form_field_type

18
Sicurezza / Re:[RISOLTO]Attacco su 2.5.9
« il: 25 Feb 2013, 15:10:39 »
Purtroppo abbiamo provato ad indagare e a cercare tra le componenti codice malevolo. Abbiamo trovato anche lo script che è stato utilizzato, ma analizzarlo e capire con esattezza porta via tempo e come già accennato da qualcuno non può diventare un lavoro.

Se sento altre segnalazioni o lamentele al riguardo della componente vedrò di far fattor comune.

19
Sicurezza / Re:[RISOLTO]Attacco su 2.5.9
« il: 19 Feb 2013, 09:07:40 »
Io so per certo hanno postato nel contenuto del messaggio uno script che poi è rimasto nei log.

20
Sicurezza / Re:Attacco su 2.5.9
« il: 18 Feb 2013, 17:39:58 »
Non avevo utilizzato alcuna delle componenti segnalate.

In primis tutto è nato da una mia dimenticanza: capcha mancante su form di contatti Fox Contact.

Ora ho rimendiato ed in più ho trovato lo script utilizzato, dal quale ho preso qualche spunto per aumentare i controlli su quanto inserito dagli utenti.

Pagine: [1] 2 3 4 ... 6


Web Design Bolzano Kreatif