Quando si parla di sicurezza informatica, o cyber-security, quella che si delinea nell’immaginario collettivo è spesso l’immagine di un individuo (il fantomatico hacker) che grazie a sofisticatissimi quanto misteriosi programmi software riesce ad entrare nei PC delle persone (o meglio nei database aziendali) per rubare dati ed informazioni sensibili.

In effetti, sempre più spesso giungono alla nostra attenzione notizie di cronaca che riportano di furti digitali perpetrati ai danni di aziende importanti ed è plausibile pensare che dietro a questi eventi ci sia effettivamente un gruppo di informatici molto esperti.

Però non è sempre così, o meglio, non è detto che si debba essere necessariamente dei maghi della programmazione per violare le applicazioni web (o quanto meno quelle che sono state sviluppate senza pensare ai rischi di una programmazione superficiale).

Senza avere la pretesa di entrare troppo a fondo nell’argomento, anche perché è decisamente molto più complesso ed articolato di quanto una persona non esperta di cyber-security come me possa immaginare, in questo articolo vorrei darti alcuni suggerimenti da tenere a mente che ti aiuteranno a sviluppare applicazioni APEX più sicure.

Prima, però, una precisazione.

Questa guida non è certo un corso sulla sicurezza informatica delle applicazioni web e probabilmente, se sei già del mestiere, conoscerai molte delle cose che andrò ad illustrare.

Il mio desiderio è semplicemente quello di creare consapevolezza, soprattutto nella testa di chi non ha mai sperimentato sulla propria pelle i rischi che si possono correre nel costruire applicazioni poco sicure.

La sicurezza nelle applicazioni APEX

Devi sapere che tutte le applicazioni web possono soffrire di specifiche vulnerabilità che devono essere sanate per evitare che utenti o sistemi malevoli possano violarle.

Se poi si parla di Oracle APEX l’argomento è ancora più delicato dato che si tratta di un framework basato su database Oracle con il quale è totalmente integrato.

Da una qualsiasi applicazione APEX puoi eseguire procedure PL-SQL, creare Report che interrogano viste e tabelle piuttosto che consumare servizi REST pubblicati tramite ORDS.

Senza le difese opportune, un hacker potrebbe effettuare quello che in gergo si chiama Application Tampering, ovvero potrebbe manomettere l’applicazione al fine di causare danni o far si che faccia operazioni non previste o autorizzate.

Vediamo, anche con l’aiuto di qualche esempi concreto, quali sono le vulnerabilità più comuni e come correggerle.

SQL Injection

Con il termine SQL Injection (chiamato brevemente SQLi) ci si riferisce ad una tecnica di Code Injection, usata per attaccare applicazioni che gestiscono dati attraverso database relazionali sfruttando il linguaggio SQL (se non te ne fossi reso conto, stiamo parlando di APEX).

Il fatto che possano esistere nella tua applicazione Page Items che vengono usati come parametri di una query o di uno script PL-SQL, permette di inserire artificiosamente delle stringhe di codice che possono essere eseguite all’interno dell’applicazione.

A causa di questa vulnerabilità è possibile eseguire comandi SQL anche molto complessi, che possono essere usati sia per estrarre informazioni altrimenti non accessibili che, nei casi peggiori, per corrompere o modificare i dati stessi.

Insomma, davvero un bel problema.

Come funziona un attacco SQL Injection in Oracle APEX

Per farti capire meglio di cosa stiamo parlando vorrei farti un esempio concreto, che puoi provare anche a replicare in autonomia.

Supponiamo di avere una semplice applicazione APEX che tramite un Report estrae i record dalla tabella EMPLOYEE usando la query seguente.

select ID, LAST_NAME, FIRST_NAME, TITLE
  from S_EMP a
 where FIRST_NAME LIKE '%&P2_FIRST_NAME.%'

&P2_FIRST_NAME. è un parametro di ricerca che viene valorizzato automaticamente da APEX con la stringa che l’utente inserisce nel Page Item P2_FIRST_NAME

Purtroppo, questo report espone il database Oracle ad un possibile attacco di tipo SQLi ed il motivo di questo sta proprio nel fatto che sto utilizzando la notazione &P2_FIRST_NAME.

Ad esempio, potrei inserire questa stringa nel campo di ricerca:

' UNION select ID,
               LAST_NAME,
               FIRST_NAME,
               TO_CHAR(SALARY)SALARY 
          from S_EMP where '%' like '

Ecco che nella colonna “Title” compare lo stipendio mensile del dipendente, informazione che tra l’altro avevo esplicitamente escluso dalla query del Report.

Vorrei sottolineare il fatto che non è stato necessario chissà quale strumento di hacking per modificare il comportamento del nostro report APEX, anzi.

Tra l’altro in questo caso mi sono limitato ad estrarre un dato (SALARY) contenuto all’interno della stessa tabella collegata al report ma ti dico fin da subito che potrei fare di peggio, molto peggio.

Ad esempio, potrei estrarre dal database tutti i record da qualsiasi tabella.

Non ci credi? Ti mostro come fare.

Supponiamo che l’hacker sappia che i dati dei clienti sono salvati nella tabella S_CUSTOMER.

Sarà sufficiente inserire questa stringa nel campo di ricerca:

''XXX' UNION ALL select null ID,
                        name LAST_NAME,
                        phone FIRST_NAME,
                        address SALARY 
                   from S_CUSTOMER 
                  where '%' like '

Ti chiederai: ma come fa un hacker a sapere quali sono le tabelle e le relative colonne della mia applicazione APEX?

Niente di più facile. è sufficiente iniettare questa query e voilà, il gioco è fatto.

SELECT table_name, 
       column_name, 
       data_type 
  FROM USER_TAB_COLUMNS

Ecco a disposizione l’elenco di tutte le tabelle del database con le relative colonne e tipo dati.

Un hacker nemmeno troppo esperto (è sufficiente sapere un po’ di SQL) è in grado di scaricare tutto il nostro database usando un banale Report APEX.

Il tutto dovuto ad un uso improprio dei parametri nella query di un banalissimo report.

Ma come può succedere tutto questo?

Devi sapere che la notazione &P_ITEM. fa si che quando uno statement SQL viene eseguito, APEX sostituisce alla variabile di binding l’esatta stringa che trova nel Page Item corrispondente.

Quindi, quando un utente malintenzionato inserisce nel campo di ricerca la stringa SQL non fa altro che riscrivere la query del report. Questo è un esempio:

C’è un modo per evitare tutto questo?

Si e tra poco vedremo quale.

Come evitare l’SQL Injection in Oracle APEX

Per salvaguardare la tua applicazione APEX da un attacco SQL Injection non devi sforzarti molto.

Sarà sufficiente passare i parametri alla tua query usando le variabili di binding nella notazione :P_ITEM

Questo vuol dire che per mettere in sicurezza la mia applicazione dovrò modificare il report usando questa query SQL

select ID, LAST_NAME, FIRST_NAME, TITLE
  from S_EMP a
 where FIRST_NAME LIKE '%'||:p3_first_name||'%'

Possiamo dirci al sicuro a questo punto?

Non proprio (lo so, è un mondo difficile…).

In effetti l’utilizzo delle variabili di binding non ci protegge dall’SQL Injection se usiamo SQL Dinamico, ad esempio quando creiamo report basati su Query Dinamiche.

In un Report basato su Query Dinamica, la definizione del report è demandata ad uno script PL-SQL fatto, ad esempio, così:

declare
   v_sql varchar2(4000);
begin
   v_sql := 'select ID, LAST_NAME, FIRST_NAME, TITLE 
               from S_EMP a 
              where FIRST_NAME LIKE ''%'||:p5_first_name||'%''';
   return v_sql;
end;

In questo caso l’applicazione soffre delle stesse vulnerabilità all’SQL Injection che abbiamo visto prima, anche se usiamo le variabili di binding.

Per correggere questa problema puoi usare due metodi.

Il primo consiste nell’includere le variabili di binding direttamente all’interno della stringa

declare
   v_sql varchar2(4000);
begin
   v_sql := 'select ID, LAST_NAME, FIRST_NAME, TITLE 
               from S_EMP a 
              where FIRST_NAME LIKE :P6_FIRST_NAME';
   return v_sql;
end;

Il secondo metodo, invece, si basa sull’utilizzo del package DBMS_ASSERT, che offre una serie di funzionalità che servono per sanificare e controllare gli input utente.

Uno di questi è la funzione enquote_literal che racchiude l’input all’interno di apici.

Questo è un esempio di utilizzo:

declare
   v_sql_1 varchar2(4000);
   
begin
   v_sql_1 := 'select ID, LAST_NAME, FIRST_NAME, TITLE 
               from S_EMP a 
              where FIRST_NAME like ' || sys.dbms_assert.enquote_literal(:p6_first_name);
              
   return v_sql_1;
end;

Ecco il risultato se provo ad iniettare del codice SQL.

Sembra funzionare.

Provo a fare un altro test ed ottengo un errore ORA-06502:PL/SQ: numeric or value error dovuto al fatto che grazie all’utilizzo della funzione sys.dbms_assert.enquote_literal lo script PL-SQL che abbiamo usato per generare la query del report non riesce a completare l’operazione.

URL Tampering

Quello che vedremo adesso è una forma di Injection che non si basa sull’iniettare del codice all’interno di una applicazione ma che invece permette ad un utente malintenzionato di accedere ad informazioni altrimenti riservate modificando semplicemente l’URL.

Vediamo di cosa si tratta.

Come funziona l’URL Tampering

Supponiamo tu abbia creato una applicazione di gestione dei dipendenti, basata su Interactive Report + Form.

Carlo, un utente dell’amministrazione che utilizza questa applicazione, grazie a questo report può interrogare e modificare le informazioni dei dipendenti che lavorano nel dipartimento di sua competenza.

Allo stesso tempo, Carlo non deve poter visualizzare né tantomeno modificare le informazioni dei dipendenti che lavorano nei dipartimenti non gestiti direttamente da lui.

Quando Carlo, che è un tipo sveglio, clicca sul bottone Edit può consultare una Form Page che mostra i dettagli dell’impiegato.

Facendo queste operazioni più e più volte nota che nell’URL del browser è visibile il parametro PX_ID che l’Interactive Report deve passare alla Form Page per mostrare le informazioni del record selezionato

La stessa informazione è visibile posizionando il mouse sul link Edit

A questo punto, poiché è un tipo intraprendente, Carlo non si fa problemi a modificare direttamente il valore del parametro PX_ID nel browser e così facendo, scopre che può sbirciare senza problemi informazioni che non avrebbe dovuto sapere.

Questo tipo di violazione è subdola perché non sono necessarie particolari competenze informatiche e può essere perpetrata da chiunque, anche dagli stessi utenti della tua applicazione.

Session State Protection

Proteggere la tua applicazione da questa vulnerabilità è molto semplice abilitando l’opzione Session State Protection che trovi in Shared Components > Security Attributes > Session State Protection

Dopodiché dovresti attivare per tutte le pagine della tua applicazione il livello di Page Access Protection più opportuno.

Esistono 4 livelli di protezione

• Unrestricted: se non desideri che venga applicata alcuna protezione.
• Arguments Must Have Checksum: selezionando questa opzione Oracle APEX concatena all’URL della pagina una stringa alfanumerica di controllo. Se un utente modifica uno dei parametri oppure elimina o modifica la stringa di checksum, allora l’accesso alla pagina è bloccato.
• No Arguments Allowed: la pagina può essere richiamata attraverso una URL ma non ammette parametri
• No URL Access: la pagina non può essere richiamata attraverso una URL

Se selezioni, ad esempio, l’opzione Arguments Must Have Checksum, qualora un utente provasse a modificare un qualsiasi parametro nell’URL riceverebbe questo messaggio di errore:

Possiamo quindi sentirci al sicuro adesso? Non ancora.

Ciò che inganna molti sviluppatori è l’idea che la funzionalità di Page Access Protection metta al sicuro una pagina APEX da qualunque manomissione ma purtroppo non è così.

Facciamo un esempio.

Supponiamo di aver creato un Report Dipartimenti che consente a Carlo di vedere solo i Dipartimenti che deve gestire.

Selezionando lo specifico dipartimento è possibile vedere tutti i dipendenti che lavorano in quel dipartimento.

P4_DEPT_ID è un Page Items che serve per far si che ciascun utente possa vedere solo i record di propria competenza.

Cliccando sull’icona Edit del singolo record è possibile vedere le informazioni dello specifico dipendente.

A differenza di quanto fatto poco fa, ipotizziamo che la pagina di dettaglio sia Unrestricted.

Avendo impostato la Page Access Protection sul report Dipartimenti siamo sicuri che l’utente non può modificare il parametro nell’URL per vedere gli impiegati associati ad altri dipartimenti.

Però l’utente può entrare nella pagina di dettaglio di uno qualsiasi dei dipendenti del dipartimento (che ti ricordo è Unrestricted) e può quindi modificare la sua URL.

In particolare, posso aggiungere il parametro P4_DEPT_ID=50 e premere invio.

Questo parametro non avrà impatto diretto sulla pagina in questione però quello che succede è che viene memorizzato nei dati di sessione.

In questo modo, quando torno al report Dipendenti ecco che verranno mostrati i dipendenti con P4_DEPT_ID=50

In questo esempio caso abbiamo sicuramente un problema, ovvero il fatto che la pagina di dettaglio del record è Unrestricted.

Tuttavia, APEX offre una protezione anche a livello di singolo Page Item.

Seleziono il Page Item P4_DEPT_ID.

Vai alla sezione Security > Session State Protection ed imposto il valore Checksum Required – Session Level

Se provi a modificare il parametro P4_DEPT_ID tramite l’URL dovresti ottenere questo errore

Abilitare questa opzione sui Page Items (in particolare quelli che sono nascosti) che rappresentano chiavi primarie oppure che vengono utilizzati per filtrare i dati è sicuramente un buon approccio.

Campi Nascosti

Oltre a proteggere i Page Items da modifiche illecite perpetrate attraverso l’URL, Oracle APEX consente un ulteriore livello di sicurezza a livello di singolo, molto utile soprattutto quando definisci all’interno della pagina campi nascosti (Hidden Items).

Questi Page Items, seppur non visibili, possono essere modificati da un utente un po’ più esperto usando la console del browser.

Se stiamo parlando di campi che poi vengono utilizzati per aggiornare le informazione nel database (come ad esempi le Primary Key delle Form Pages) è bene assicurarsi che non possano essere assolutamente modificati, nemmeno da uno script JS o da browser console.

Per questo motivo assicurati che sia attivata l’opzione Value Protected.

Cross Site Scripting (XSS)

Gli attacchi Cross Site Scripting (chiamati anche XSS) sono usati per iniettare all’interno di una pagina web del codice (generalmente JavaScript) che viene usato per manipolare il comportamento della pagina oppure per visualizzare o modificare dati sul server.

Se ci pensi, come l’SQL Injection anche l’XSS è una forma di Injection nella sua definizione più pura e per questo motivo è importante evitare che le applicazioni APEX ne possano soffrire.

Per capire di cosa siamo parlando facciamo un esempio.

Come funziona un attacco XSS in Oracle APEX

Supponiamo di aver implementato un Interactive Report come quello riportato in figura.

Noi sappiamo che nella colonna FRUIT_DESCRIPTION può essere inserito del codice HTML, peccato che quando proviamo a visualizzare il report otteniamo questo risultato, non molto esaltante.

Ecco, quindi, che decidiamo di disattivare l’opzione Escape Special Characters del Page Item FRUIT_DESCRIPTION

Questo è il risultato che otteniamo, decisamente molto più gradevole alla vista

Quello che non sappiamo è che così facendo abbiamo introdotto una vulnerabilità XSS di tipo Persistente.

Supponiamo, infatti, che questa sia la Form Page che l’utente deve utilizzare per aggiornare il record.

Potrei iniettare del codice JavaScript semplicemente andando ad inserire la seguente stringa nel campo Fruit Description.

<script>alert('Hello');</script>

L’effetto spiacevole sarà che tutte le volte che qualcuno aprirà il report, verrà eseguito il codice JavaScript.

In questo caso mi sono limitato a stampare un messaggio a video, ma penso tu possa immaginare quanto questa operazione possa essere dannosa.

Come evitare attacchi XSS in Oracle APEX

Cosa possiamo fare per evitare che la nostra applicazione APEX possa subire un attacco XSS?

Principalmente due cose.

La prima cosa da fare è evitare di disattivare l’opzione Escape Special Characters che abbiamo visto qualche secondo fa.

Così facendo, qualora per qualche motivo venga inserito del codice JavaScript, quest’ultimo sarà sempre bloccato e non potrà mai essere eseguito.

A questo punto però ti chiederai: bene, ma adesso come visualizzo nella mia applicazione del contenuto HTML? Ovviamente dipende dal rischio che puoi o vuoi assumerti.

Se sei sicuro che il contenuto HTML che viene letto dal database è sicuro (tra poco vedremo come fare) potresti visualizzarlo formattato usando una colonna di tipo Rich Text configurata per mostrare contenuto in formato HTML.

Così facendo viene preservata la formattazione HTML tanto desiderata

Se invece non sei sicuro del codice HTML da mostrare puoi usare una colonna di tipo Remove HTML: probabilmente questa è la scelta migliore.

La seconda precauzione da prendere per evitare che un utente salvi in maniera persistente nel database del codice JavaScript potenzialmente dannoso, è validare i Text Input.

In particolar modo, possiamo far si che non possano essere accettati particolari caratteri che se inseriti potrebbero causare un attacco XSS.

Con riferimento alla Form Page che abbiamo creato per popolare la colonna Fruit Description, potresti specificare nella proprietà Restricted Characters l’opzione Blocklist HTML

Se un utente prova ad inserire tag HTML ottiene il seguente messaggio di errore:

E se devi gestire del contenuto HTML validato? Puoi sempre usare un Page Item di tipo Rich Text.

Controlla Accessi e le Autorizzazioni

Gestire gli accessi e le autorizzazioni significa stabilire prima di tutto chi può usare una applicazione e poi in che modo.

Questo significa che gli utenti devono essere opportunamente profilati pe una volta autenticati possono fare solo le operazioni che sono autorizzati a fare.

Vediamo cosa puoi fare per garantire tutto questo.

Implementa uno Schema di Autenticazione Adeguato

Tutte le applicazioni Oracle APEX nascono di default con impostato uno schema di autenticazione base, chiamato Application Express Accounts.

In questo caso le utenze applicative vanno create direttamente dall’area di amministrazione di Oracle APEX (leggi qui se non sai di cosa sto parlando) e sono salvate direttamente nel database di Oracle APEX.

La scelta di utilizzare APEX per gestire le utenze non è certamente un problema, tuttavia vale la pena sapere che ci sono molte altre possibilità che garantiscono un maggiore grado di sicurezza e privacy.

Ad esempio puoi implementare il Social Login con praticamente tutte le maggiori piattaforme come Facebook, Google o Linkedin oppure puoi avvalerti di servizi di Identity Management come Oracle Identity Cloud Service.

Puoi utilizzare LDAP, Single Sign On oppure creare un tuo schema di autenticazione totalmente custom.

Quale sia il modo più corretto da usare dipende ovviamente dalle tue esigenze, tuttavia vale la pena sapere che da questo punto di vista APEX è davvero molto flessibile.

Una cosa che vale la pena tenere in considerazione, soprattutto quando si creano applicazioni che manipolano dati sensibili, è un meccanismo di autenticazione a due fattori.

Utilizza gli Schemi di Autorizzazione

Il controllo degli accessi impone la necessità di definire dei criteri affinché gli utenti non possano agire al di fuori delle autorizzazioni previste.

Ad esempio, ci potrebbero essere utenti che devono utilizzare specifiche funzionalità oppure non possono accedere a determinate pagine.

Per attivare questi tipi di controllo è necessario assegnare gli schemi di autorizzazione a quelle parti della nostra applicazione che non vogliamo vengano utilizzate impropriamente.

Configura i Parametri di Sessione

Per ciascuna applicazione puoi configurare una serie di parametri che servono per evitare, ad esempio, che un utente possa lasciare attiva una sessione a tempo indefinito.

Puoi trovare questi parametri sotto Shared Components > Security Attributes > Session Management.

Una configurazione tipo potrebbe essere questa:

• Rejoin Sessions: Disabled
• Deep Linking: Disabled

Disattivando l’opzione Rejoin Sessions evitiamo che qualcuno possa utilizzare o manipolare le sessioni recuperandole dai cookie del browser.

L’opzione Deep Linking determina invece come si comporta APEX quando un utente si ricollega all’applicazione dopo che la sessione è scaduta: disattivando l’opzione Deep Linking se l’ID di sessione non è più valido l’applicazione viene reindirizzata all’Home Page, viceversa riparte dal punto in cui si trovava.

Questa opzione è importante perché i browser moderni cercano spesso di ripristinare le sessioni dopo un riavvio, causando un deep link.

Purtroppo questo comportamento potrebbe causare dei problemi se l’URL salvata fa riferimento ad una pagina non valida o che dovrebbe essere raggiunta solo dopo aver eseguito specifici passaggi all’interno dell’applicazione (ad esempio con un wizard).

Configura i Servizi REST utilizzando il protocollo OAuth 2.0

Una delle funzionalità più interessanti che offre Oracle APEX è quella di poter creare e pubblicare servizi RESTful utilizzando Oracle REST Data Services (ORDS).

Un aspetto da tenere a mente quando si realizzano dei microservizi consiste nel tipo di autenticazione che il client deve usare per sfruttarli.

Il mio consiglio è di utilizzare il protocollo OAuth 2 (abbreviazione di Open Authorization).

Se vuoi saperne di più ho scritto un articolo come configurare OAuth 2.0 per un servizio REST in Oracle APEX.

Proteggi i Dati Sensibili

Al giorno d’oggi le applicazioni arrivano a gestire tantissimi dati, molti dei quali sensibili: password, numeri delle carte di credito, dati personali e aziendali.

Il furto o la manomissione di queste informazioni non è solo dannosa ma può avere anche risvolti di natura legale: ad esempio in Europa il GDPR vincola gli amministratori di queste applicazioni ad intraprendere tutte le azioni necessarie affinché non siano possibili furti e/o manomissioni dei dati personali.

Insomma, mettere in sicurezza i dati non è qualcosa che possa essere trascurato.

Ma cosa significa e cosa bisogna fare?

Devo essere onesto: il tema è davvero molto ampio e copre diversi aspetti possono essere applicati a diversi livelli che ed è praticamente impossibile sviscerarlo in un articolo.

Tuttavia penso di poterti dare alcune indicazioni di carattere generale specifico per le applicazioni create con Oracle APEX e basate, quindi, sul database Oracle.

Utilizza il protocollo HTTPS

Se utilizzi Oracle APEX in Oracle Cloud questo non è un problema.

Se invece lavori su una istanza On-Premise chiedi al tuo amministratore di sistema o DBA di configurare un certificato HTTPS su tutte le istanze APEX (non solo l’ambiente di produzione, ma anche eventuali ambienti di sviluppo e testing).

Assicurati, inoltre, che anche eventuali servizi REST pubblicati attraverso ORDS possano essere utilizzati solo tramite protocollo HTTPS.

Una volta che è stato installato un certificato HTTPS puoi assicurarti che ne venga forzato l’uso attivando l’opzione Require HTTPS.

• Collegati alla Console di Amministrazione dell’istanza APEX (attenzione, non è l’APP Builder)
• Vai in Manage Instance > Security
• Imposta l’opzione Require HTTPS = Always

Item Encryption

Quando un utente utilizza una applicazione APEX lo stato della sessione e i valori dei Page Items utilizzati dall’utente sono salvati in chiaro in una tabella del database chiamata WWV_FLOW_DATA e possono essere esplorati usando in modalità debug.

In questa situazione un DBA curioso potrebbe potenzialmente vedere informazioni riservate.

Per evitare questo possiamo criptare i valori di sessione attivando l’opzione Store value encrypted in session state.

Conclusione e Risorse Utili

Bene, direi che per il momento è tutto anche se, come forse immaginerai, potremmo dire tante altre cose.

Non possiamo certamente definirci degli esperti di cyber-security, ma sicuramente abbiamo in mano alcune linee guida concrete utili per sviluppare applicazioni APEX più sicure.

Se comunque l’argomento ti interessa e desideri approfondirlo, ho riportato qui sotto alcune risorse utili che puoi consultare.

Un abbraccio

Daniele

Oracle APEX – Managing Application Security

Un buon punto di partenza è sicuramente la documentazione ufficiale, dove puoi trovare con le linee guida, suggerite direttamente dal team di sviluppo APEX, per gestire in modo accurato la sicurezza della applicazioni web.

APEX Security Checklist – Scott Spendolini

Un sessione APEX@Home in cui Scott Spendolini illustra le principali criticità di APEX in tema di sicurezza ed espone metodologie e trucchi per gestire al meglio (tra l’altro è da questo video che ho attinto gran parte dei contenuti esposti in questo articolo).

APEX-SERT

APEX-SERT è un’applicazione APEX Open Source che valuta le tue applicazioni APEX per le vulnerabilità della sicurezza.

Si installa come una qualsiasi altra applicazione ed è immediatamente disponibile per tutti gli sviluppatori che lavorano nell’APP Builder.

Puoi scaricare l’applicazione dal progetto GitHub di APEX-SERT.

OWASP Top Ten

OWASP è un’iniziativa no-profit internazionale nata con l’obiettivo di divulgare quali sono i pericoli informatici più importanti per il mondo dei software web.

Tra i vari report che OWASP pubblica periodicamente, quello sicuramente più interessante per iniziare è il report OWASP Top 10 che riporta le 10 criticità più importanti.