Securing your API and mobile application - API Connection FR
API
Connec*on
16
Juin
2015
Paris
-‐
France
Sébas&en
Gioria
Sebas*en.Gioria@owasp.org
Chapter
Leader
&
Evangelist
OWASP
France
API
:
les
risques
technologiques
et
les
bonnes
pra*ques
2
http://www.google.fr/#q=sebastien gioria
• Innova*on
and
Technology
@Advens
&&
Applica*on
Security
Expert
• OWASP
France
Leader
&
Founder
&
Evangelist,
• OWASP
ISO
Project
&
OWASP
SonarQube
Project
Leader
• Applica*on
Security
group
leader
for
the
CLUSIF
• Legal
Expert
at
Cour
of
Appeal
of
Poi*ers
• Proud
father
of
youngs
kids
trying
to
hack
my
digital
life
Twitter :@SPoint/@OWASP_France
2
Agenda
• Pourquoi
parler
de
sécurité
API
?
• OWASP
?
• Que
trouve-‐t-‐on
dans
une
applica*on
?
• Sécuriser
son
API
en
4(,2)
minutes
3
Sécurité
des
API
?
4
Votre application sera
piratée
Laissez moi
vous mettre
sur le bon
chemin 4
Votre
application
a des
chances
d'être
piratée ?
Votre
application
a été
piratée
OUI
NON
NON
OUI
OK,
Allons
y
Nous
vivons
dans
un
monde
connecté
en
permanence,
dans
un
environnement
Digital.
v La
plupart
des
applica*ons
et
sites
Web
sont
vulnérables
à
99%
v Le
business
est
basé
majoritairement
sur
des
applica*ons
de
type
Webs
(Services,
Online
Store,
Self-‐care,
Telcos,
SCADA,
...)
Sécurité
Applica*ve
Age
de
l'an*virus
Age
de
la
sécurité
périmétrique
Age
de
la
sécurité
Applica*ve
5
Open
Web
Applica*on
Security
Project
• OWASP
Moto
:
“Making
Applica*on
Security
Visible”
• Né
en
2001
• Fonda*on
américaine,
en
France
une
associa*on
• Citée
dans
des
tas
de
standards
et
recommanda*ons:
– PCI-‐DSS
(Chapitres
6.5
&&
6.6)
– NIST
– ANSSI
guides,
– ....
• L'OWASP
c'est
:
– des
Ou*ls
,
– des
API,
– de
la
Documenta*on,
– des
Conférences,
– des
Blogs,
– du
Contenu
audio/video
:
youtube,
podcast,
....
Connaître
son
ennemi
“On
ne
peut
pas
créer
une
applica*on,
tant
que
l'on
ne
sait
pas
comment
elle
sera
piratée"
Thanks
to
Royston
Robertson
www.roystonrobertson.co.uk
for
permission
to
use
his
cartoon!
Connaître
son
ennemi
• Concevoir
l'API
avec
une
approche
u*lisateur
– Les
pirates
sont
astucieux,
il
faut
imposer
les
scénarios
u*lisateurs
• Ne
pas
se
contenter
de
sécuriser
le
lien
le
plus
faible
• Modéliser
les
amaques
sur
l'API
– Connaître
les
fron*ères
de
confiance
Chiffrer
le
trafic
et
sécuriser
les
iden*fiants
• Ne
pas
stocker
de
secret
sur
le
client
– U*liser
l'authen*fica*on
sur
le
serveur
le
plus
souvent
possible
– U*liser
les
mécanismes
de
coffre
fort
lorsqu'ils
sont
disponibles
et
qu'un
stockage
sur
le
client
est
nécessaire
• Imposer
TLS
par
défaut
dans
toutes
les
communica*ons
– Cela
ne
change
pas
grand
chose
de
plus
qu'un
's'
dans
l'URL.
Surveiller
le
trafic
• Ne
pas
tracer
que
les
éléments
en
erreurs…
– Les
amaques
par
"scrapping"
u*lisent
des
requêtes
correctes...
• Réagir
à
des
trafics
innatendus
– Début
d'une
amaque
par
"scrapping"
?
• Le
Big
Data
et
les
SIEM
peuvent
permemre
de
trouver
correctement
les
amaques
Sécuriser
le
code
• Former
les
chefs
de
projets,
les
dévelopeurs,
les
architectes,
à
la
sécurité
applica*ve.
• Tester
et
analyser
son
code
avec
des
ou*ls
et
des
êtres
humains
– SAST
– DAST
– RASP
• U*liser
les
guides
et
documenta*ons
de
Secure
Coding
OWASP
et
du
CERT.