www.scriptcasecommunity.it

Salve.
La recente notizia di un attacco tramite sql injection fatto su un sito del governo italiano ha destato in me delle domande.
Non so quasi nulla sull'argomento quindi scusate se farò qualche domanda un pò stupida o ingenua.

Da ciò che ho letto l'attacco fatto tramite sql injection è dipeso da vulnerabilità a livello applicativo.
In questo caso particolare l'hacker ha fatto un export completo del db sfruttando la non messa in sicurezza del front end pubblico..


Mi domando:
1) le applicazioni generate da SC sono "sicure" da questo punto di vista, Cioè tengono conto di attacchi di questo genere?
2) la sicurezza, in questo senso, dipende invece da come noi costruiamo le applicazioni?
3) se è cosi, quali sono le buone pratiche da usare o azioni da evitare assolutamente per scongiurare questo rischio?
4) il modulo security di SC, scongiura questo rischio? (dando per scontato che chi si logga e accede alle applicazioni in quanto accreditato, non compia azioni di questo tipo)
5) le credenziali del db con il quale colleghiamo l'applicazione al db stesso, devono per forza essere db administrator? Oppure sarebbe meglio che non lo fossero?
6) Se l'account non fosse db administrator e impedissimo l'export del db a questo account (a livello db), le funzioni di export delle applicazioni SC, funzionerebbero lo stesso?

Ora, nel progetto a cui sto lavorando non è prevista l'esposizione pubblica del front end, ma nel caso in futuro mi capitasse vorrei capirne qualcosa di più.
Mi rendo conto che sono un pò di domande, ma se qualcuno esperto in questo senso volesse rispondere credo possa generarsi una discussione utile a tutti. Soprattutto ai meno esperti come me.
Inoltre credo che la sicurezza non sia mai un argomento troppo dibattuto.
Grazie

Nella guida ho trovato questo:

sc_sql_injection({My_Field}) or ($My_Variable)
This macro its used to protect the field/variable against "sql injection".

Macro used for protection against "sql injection" in commands generated by the developer when using the macros: sc_lookup, sc_select or sc_exec_sql.


Ex. 1: Protecting a local variable:
$field_protect = sc_sql_injection({my_field});


Ex. 2: Protecting an user variable:
$field_protect = sc_sql_injection($my_var);

Note: that all database accesses, generated for the Scriptcase, have protection against "sql injection".
quindi mi sembra di capire che le applicazioni sono protette a meno che non usi le macro sc_lookup, sc_select or sc_exec_sql.

Io faccio molto uso delle macro sc_lookup.
Non mi è chiaro come dovrei usare sc_sql_injection. Forse così?

evento onload di un form

sc_lookup(dataset, "SELECT campo_tabella FROM tabella WHERE id = '".{id}."'");

$dataset = {dataset[0][0]} ;

$field_protect = sc_sql_injection($dataset);

{campo_form} = $field_protect ;

Esatto.
Con questa macro SC mette in sicurezza il database contro gli sql injections.
Nel modulo sicurezza questa macro viene utilizzata in automatico.
Resta comunque a carico degli sviluppatori adottare tutti gli accorgimenti possibili.

Non mi è chiara una cosa:

se io utilizzo la macro laddove uso sc_lookup e poi applico il modulo security è ridondante?
oppure devo comunque farlo laddove uso quelle macro a prescindere che poi utilizzi il modulo security?

Grazie

Domanda interessante e si tutto dipende dall applicativo ovvero da come si preparano i campi destinati a eseguire attività sul db.

mhanu70 ha scritto:Salve.

Mi domando:
1) le applicazioni generate da SC sono "sicure" da questo punto di vista, Cioè tengono conto di attacchi di questo genere?

dipende da come sono disegnate in linea di massima si se si usano le varie funzioni di supporto alla ricerca . insomma se l argomento da ricercare lo fai selezionare si , sei in un buon livello di sicurezza , se permetti un libero uso di stringhe no.

mhanu70 ha scritto: 2) la sicurezza, in questo senso, dipende invece da come noi costruiamo le applicazioni?

Si , mi pare ovvio .

mhanu70 ha scritto: 3) se è cosi, quali sono le buone pratiche da usare o azioni da evitare assolutamente per scongiurare questo rischio?

in particolare analizzare le stringhe che si usano per fare ricerche
in Sc l uso della macro sc_sql_injection
tieni conto che tutti gli accessi generati da Sc hanno di default l analisi anti injecton, quindi se non permetti all utente di crearsi la query sei a cavallo

mhanu70 ha scritto: 4) il modulo security di SC, scongiura questo rischio? (dando per scontato che chi si logga e accede alle applicazioni in quanto accreditato, non compia azioni di questo tipo)

in ambito di sicurezza mai dare nulla per scontato , mai . La sicurezza Sc serve solo per l accesso alle app non alla banca dati. l accesso al db è solo derivato dall app.

mhanu70 ha scritto: 5) le credenziali del db con il quale colleghiamo l'applicazione al db stesso, devono per forza essere db administrator? Oppure sarebbe meglio che non lo fossero?

assolutamente no, deve solo essere un utente con le dovute autorizzazioni sulle tabelle . potendo variare la connessione a tempo di esecuzione nulla ti vieta per esempio di creare piu profili di accesso con autorizzazioni profondamente diverse sulle tabelle .

mhanu70 ha scritto: 6) Se l'account non fosse db administrator e impedissimo l'export del db a questo account (a livello db), le funzioni di export delle applicazioni SC, funzionerebbero lo stesso?

una volta che vedo i risutlati a video , che sia export o altro , li ho e ne posso fare ciò che voglio

mhanu70 ha scritto: Ora, nel progetto a cui sto lavorando non è prevista l'esposizione pubblica del front end, ma nel caso in futuro mi capitasse vorrei capirne qualcosa di più.
Mi rendo conto che sono un pò di domande, ma se qualcuno esperto in questo senso volesse rispondere credo possa generarsi una discussione utile a tutti. Soprattutto ai meno esperti come me.
Inoltre credo che la sicurezza non sia mai un argomento troppo dibattuto.
Grazie

La sicurezza è un argomento primario per altro richiamato da normative europee, vedasi il nuovo reoglamento sulla protezione dei dati personali.
Un cattivo approccio alla protezione del dato può comportare problematiche estremamente onerose , sanzioni calcolate sul fatturato aziendale, e con risvolti penali.
Non se ne parla mai abbastanza specie in italia dove la sicurezza in generale è sempre vista come una cosa aleatoria.

dipende da come sono disegnate in linea di massima si se si usano le varie funzioni di supporto alla ricerca . insomma se l argomento da ricercare lo fai selezionare si , sei in un buon livello di sicurezza , se permetti un libero uso di stringhe no.

Intendi nella ricerca avanzata ad esempio? per i campi di testo solo opzioni scelte da me, per i campi numerici invece ho specificato opzioni tipo: maggiore di, minore di, etc...è questo che intendi con un libero uso di stringhe?

tieni conto che tutti gli accessi generati da Sc hanno di default l analisi anti injecton, quindi se non permetti all utente di crearsi la query sei a cavallo

Non sapevo di questa possibilità, potresti farmi un esempio in questo senso? Ti riferisci sempre ad un campo libero della ricerca nella quale permetto qualunque stringa?

potendo variare la connessione a tempo di esecuzione nulla ti vieta per esempio di creare piu profili di accesso con autorizzazioni profondamente diverse sulle tabelle

Cosa vuol dire variare la connessione a tempo di esecuzione? Io pensavo di creare un account con solo read; insert; update e magari usare quello.
E' una cosa diversa?

Grazie