Chap e 6
Au oma ed Assis ance o he Secu i y
Assessmen o API o Financial Se ices
By And ea Bisegna, Robe o Ca bone, Ma iano Cecca o,
Sal a o e Man edi, Sil io Ranise, Giada Scia e a,
Alessand o Tomasi and Emanuele Viglianisi
Copy igh © 2020 And ea Bisegna e al.
DOI: 10.1561/9781680836875.ch6
The wo k will be a ailable online open access and go e ned by he C ea i e Commons “A ibu ion-Non
Comme cial” License (CC BY-NC), acco ding o h ps://c ea i ecommons.o g/licenses/by-nc/4.0/
Published in Cybe -Physical Th ea In elligence o C i ical In as uc u es Secu i y: A Guide o In eg a ed Cybe -
Physical P o ec ion o Mode n C i ical In as uc u es by John Solda os, James Philpo and Gab iele Giun a (eds.).
2020. ISBN 978-1-68083-686-8. E-ISBN 978-1-68083-687-5.
Sugges ed ci a ion: And ea Bisegna e al. 2020. “Au oma ed Assis ance o he Secu i y Assessmen o API o
Financial Se ices” in Cybe -Physical Th ea In elligence o C i ical In as uc u es Secu i y: A Guide o In eg a ed
Cybe -Physical P o ec ion o Mode n C i ical In as uc u es. Edi ed by John Solda os, James Philpo and Gab iele
Giun a. pp. 94–103. Now Publishe s. DOI: 10.1561/9781680836875.ch6.
This chap e p esen s he challenges ela ed o he secu i y assessmen and he au o-
ma ed syn hesis o mi iga ion measu es o APIs o inancial se ices. The ocus is
on he APIs suppo ing he implemen a ion o he new Paymen Se ices Di ec-
i e [PSD2]. I also gi es an o e iew o an inno a i e app oach o add ess hese
challenges by (i) he au oma ed iden i ica ion and mi iga ion o secu i y miscon-
igu a ions unde lying sessions based on T anspo Laye Secu i y [TLS], which is
ubiqui ously used o build a ounda ion laye o secu i y; and (ii) he au oma ed
pene a ion es ing and syn hesis o mi iga ions o he unc ionali ies p o ided by
APIs buil on op o i , bo h business (e.g., paymen s) and secu i y (e.g., au hen ica-
ion o au ho iza ion). The main no el y o he p oposed app oach lies in he igh
in eg a ion o iden i ica ion and mi iga ion phases by means o ac ionable mea-
su es ha allow use s o signi ican ly s eng hen he secu i y pos u e o he en i e
API ecosys em.
94
Open Banking API Secu i y Recommenda ions 95
The Regula o y Landscape
The Elec onic Iden i ica ion, Au hen ica ion and T us Se ices [eIDAS] Regu-
la ion is he keys one egula ion ha de ines equi emen s g an ing legal alidi y
h oughou he in e nal ma ke o elec onic ansac ions, equi alen o p e ious
pape -based documen s. To ha end, i egula es Quali ied Ce i ica es (QC), elec-
onic seals and signa u es, and us se ice p o ide s. Secu i y guidelines o he
app op ia e use o QCs ha e been published by ENISA QTS [ENISA QTS].
The Re ised Di ec i e on Paymen Se ices [PSD2] is in ended o p o ec
and p omo e compe i ion in he in e nal ma ke by manda ing ha Accoun
Se icing Paymen Se ice P o ide s (ASPSP)—mos likely adi ional banking
ins i u ions—open hei se ices o Thi d-pa y P o ide s (TPP) o Se ices includ-
ing accoun in o ma ion (AISP) and paymen ini ia ion (PISP) p o ide s.
The Regula o y Technical S anda d [RTS] de ines equi emen s on he use o
QCs o websi e au hen ica ion and elec onic seals o communica ion among
TPPs and ASPSPs. Guidance on he use o QCs is included in [EBA-OP-2018-7].
The [ETSI TS 119 495] s anda d de ines how o implemen he equi emen s
o he RTS o use o QCs o mee he egula o y equi emen s o PSD2. Fo
ins ance, i de ines he equi emen s o Quali ied Websi e Au hen ica ion Ce -
i ica es (QWACs), and i cla i ies speci ically ha a QWAC “should be used o
es ablish a secu e TLS channel o p o ec he communica ion (in he anspo
laye ) om po en ial a acke s on he ne wo k.”
Open Banking API Secu i y Recommenda ions
Unde PSD2, banks a e o p o ide an in e ace o hi d pa ies o access accoun
in o ma ion and pe o m ope a ions (e.g., paymen s) on behal o he accoun
holde . The egula ion does no speci y echnical solu ions.
The Be lin G oup s anda ds and ha moniza ion ini ia i e p oposes se e al pos-
sible app oaches in i s de ailed “Access o Accoun (XS2A) F amewo k,” including
XML/JSON da a model and associa ed messaging, as well as OpenAPI iles o assis
de elope s wi h implemen a ion. A i s co e, XS2A p o ides a de ailed desc ip ion
o REST API and hei usage o he pu poses o au hen ica ion o in ol ed pa ies
and au ho iza ion o access Se ice esou ces, such as Accoun In o ma ion (AIS),
Paymen Ini ia ion (PIS), and Con i ma ion o Funds (PIIS).
The secu i y o hese APIs is based on bo h he anspo and applica ion laye s.
The i s co e echnology explici ly iden i ied by he guidelines is he T anspo
Laye Secu i y [TLS] p o ocol: in pa icula , “ he communica ion be ween he TPP
and he ASPSP is always secu ed by using a TLS-connec ion using TLS e sion 1.2
96 Secu i y Assessmen o API o Financial Se ices
o highe .”1[XS2A-IG]. Addi ionally, [XS2A-IG] equi es mu ual au hen ica ion
o TPP and ASPSP using eIDAS- and RTS-complian QCs, which mus include
all he oles o which he TPP is au ho ized.
On he applica ion laye , he co e echnology o au ho iza ion is he Open
Au ho iza ion P o ocol [OAu h2], in pa icula he “Au ho isa ion Code G an ”
low is manda ed o PIS and AIS. While o he op ions a e a ailable and discussed
below, OAu h is seen as p e e able.
S ong Cus ome Au hen ica ion in XS2A
S ong Cus ome Au hen ica ion (SCA) is one o he main equi emen s se ou
by PSD2 (a icle 97) and RTS (Chap e III). The ASPSP mus de e mine how o
en o ce SCA on a pe - ansac ion basis, in compliance wi h hose equi emen s.
In he XS2A amewo k, TPPs ha e h ee b oad ca ego ies o op ions o allow
compliance wi h SCA equi emen s:
1. Redi ec ion—o use s o hei accoun holde s and back o he TPP—using
an au hen ica ion solu ion based on, e.g., OAu h 2, such as [OIDC];
2. Decoupling, in which he communica ion be ween use and accoun holde
p oceeds on an en i ely sepa a e channel; and
3. Embedding, in which he TPP has o embed he PSP’s en i e SCA low in
hei own app.
App oach 3 in ol es a deep le el o in eg a ion wi h e e y single accoun holde ,
which is much mo e wo k han he o he op ions and equi es an ex emely high
le el o us be ween he pa ies as i equi es he sha ing o use c eden ials.
App oach 2 is mo e ligh weigh and scalable bu incu s a highe isk o hanging
business p ocesses as he TPP mus wai o no i ica ion o a comple ed ope a ion
on a sepa a e channel. Op ion 1 is clea ly seen as p e e able.
App oach Redi ec (OAu h 2) Decoupled Embedded
SCA Di ec ly be ween use and PSP En i ely a XS2A in e ace
Thi d-pa y
P o ide
Does no need de ailed
in o ma ion abou he
indi idual s eps o SCA
No impac on he
use /p o ide in e ace
Needs SCA de ails o he
use , e.g., displays
challenge
Example S anda d in e ace, e.g.,
“scope” a ibu e o
au hen ica ion eques is
linked o paymen ini ia ion o
consen esou ce
Push no i ica ion wi h
paymen ansac ion
de ails o dedica ed mobile
app o ia any o he
applica ion o de ice,
independen o online
banking on -end
Use s en e use name and
passwo d h ough hei
b owse and a e shown a
QR code o be scanned
1. We no e ha TLS 1.2 is now o icially ma ked as obsole e; TLS 1.3 is he cu en s anda d.
Au oma ed Analysis o TLS 97
Au oma ed Analysis o TLS
T anspo Laye Secu i y [TLS] consis s o a se o c yp og aphic p o ocols designed
o p o ide secu e communica ions o e a ne wo k. The popula i y o TLS has
encou aged a acke s o ind ulne abili ies and de elop exploi s. The a ie y o
known a acks is he esul o (i) main aining backwa d compa ibili y and (ii) e ol -
ing use-case scena ios in which TLS is deployed.
One canno “jus deploy” TLS. Se ing up a TLS se e equi es some amoun
o con igu a ion, including:
•Choosing a se o ciphe (s);
•Choosing he e sions o TLS o be o e ed;
•Se ing a ce i ica e issued by a us wo hy CA;
•Coping wi h implemen a ion issues (e.g., ulne able lib a ies).
Se e al ools ha e been de eloped o help adminis a o s deploy secu e TLS
ins ances. While such ools a e qui e e ec i e in au oma ically inding ulne a-
bili ies and issuing wa nings abou possible a acks, he bu den o inding adequa e
mi iga ion measu es is le o adminis a o s who mus i s collec in o ma ion
abou he iden i ied p oblem and ela ed ixes. Typically, such in o ma ion is dis-
ibu ed in se e al sou ces anging om scien i ic pape s o blog pos s. E en dis e-
ga ding he e o o collec enough ma e ial o enac a mi iga ion, adminis a o s
should ha e enough skills o unde s and he o en sub le de ails and u n he in o -
ma ion in a conc e e s a egy o ix he p oblem. Addi ionally, each ool has a y-
ing deg ees o co e age and does no speci y mi iga ions o he issues iden i ied.
In o he wo ds, he e is a p oblem in making he ools’ epo s ac ionable.
To add ess hese issues, we de eloped TLS Assis an [MRS19], an open sou ce
ool ha combines s a e-o - he-a TLS analyze s wi h a epo sys em ha shows
he ull se o iable a acks and sugges s app op ia e mi iga ions. The ool’s a chi-
ec u e is summa ized in Figu e 6.1. I s goal is o assis an adminis a o in secu ing
TLS con igu a ions by:
•De ec ing TLS and HTTPS miscon igu a ions;
•P o iding
◦A b ie a ack desc ip ion;
◦A mi iga ion desc ip ion;
◦Mi iga ion code snippe s ( o Apache and nginx web se e ).
We success ully es ed he use o TLSAssis an in he deploymen o an eIDAS
solu ion based on he new I alian iden i y ca ds be o e i s submission o eIDAS
no i ica ion, disco e ing ha he i s elease was p one o Lucky 13 [AFP13]
98 Secu i y Assessmen o API o Financial Se ices
Figu e 6.1. TLSAssis an wo k low.
and 3SHAKE [BDLFPS14]. The se e -side ulne abili ies issues we e p omp ly
pa ched, and he epo was judged o be bo h easy o ead and comple e.
REST ul API Secu i y Tes ing
API secu i y issues can ha e a se ious impac on all he applica ions ha
depend on hem. Indeed, no only is he e a g owing business o API man-
agemen [GMQAPI19] bu he e is a dedica ed [OWASP API] op 10 secu i y
issue lis , o which we highligh “API2:2019 B oken Use Au hen ica ion” and
“API7:2019 Secu i y Miscon igu a ion.” Fo example, he Ha bo en e p ise docke
con aine managemen se ice was ound o expose a “POST /api/use s” egis a-
ion API in which new use s could sel - egis e and injec a “HasAdminRole= ue”
a ibu e, he eby moun ing an escala ion o p i ilege a ack emo ely on any se ice
exposing his API—see [CVE-2019-16097].
Speci ically in he inancial sec o , a epo by T endMic o [HMcAM19] high-
ligh s challenges a ising om he new pa adigm, o ins ance, due o he di e en
us model unde pinning he open banking amewo k. Among se e al issues, he
basic building block o au ho iza ion p o ocols is s ill a wo k in p og ess.
While OAu h 2.0 is a guably he de ac o s anda d o au ho iza ion p o ocols,
i is a amily o p o iles ailo ed o speci ic use cases and scena ios. The highe
secu i y equi emen s inhe en o he inancial sec o and he in insic no el y o
exposing banking APIs o hi d pa ies ha e p omp ed he es ablishmen o a wo k-
ing g oup o a dedica ed Financial-g ade API p o ile [FAPI], designed o ha den
OAu h unde mo e ad e sa ial ci cums ances— o ins ance, by assuming ha sen-
si i e okens can be leaked by he use ’s b owse o ope a ing sys em, as is he case
o many man-in- he-middle a acks, and allowing o he possibili y ha API end-
poin s may be miscon igu ed. Se e al mi iga ions ha e been p oposed, o ins ance,
equi ing he use o mu ual TLS be ween hi d pa ies and accoun p o ide s;
ne e heless, esea che s in [FHK19] ound ha he expec ed secu i y p ope ies
REST ul API Secu i y Tes ing 99
did no appea o hold in all cases, o ins ance, allowing malicious ac o s o o ce
an hones TPP o pe o m w i e-like ope a ions (e.g., paymen au ho iza ions) om
he a acke ’s de ice on an hones use ’s accoun .
We no e ha he use o OAu h on i s own o au hen ica ion is conside ed
imp ope ; he OpenID Connec [OIDC] p o ocol builds an au hen ica ion laye
on op o OAu h, and indeed, his is used in FAPI.
Au oma ed Black-box Tes ing o REST ul APIs
We de eloped a syn hesis o unc ional and secu i y black-box es s, o appea in
[VDC20]. I allows he au oma ic gene a ion o es cases o REST ul API agains
e o s and ulne abili ies. Indeed, e o s can be indica o s o po en ial ulne abili-
ies ha may be exploi ed o moun a acks.
The ool’s a chi ec u e is summa ized in Figu e 6.2. I akes as inpu an OpenAPI
speci ica ion, con aining all he necessa y in o ma ion o each he API and he
desc ip ion o he endpoin s. The i s module gene a es an Ope a ion Dependency
G aph ha , oge he wi h he Swagge speci ica ion, is gi en as inpu pa ame e
o he Nominal Tes e module in o de o es he API’s nominal beha io . The
Nominal Tes e ou pu s he nominal es cases and a se o s uc u ed epo s ha
a e gi en as inpu o bo h E o Tes e and Secu i y Tes e . The o me es s he
Figu e 6.2. Black-box ool wo k low.
100 Secu i y Assessmen o API o Financial Se ices
co ec e o handling in case o mal o med eques s, o example, missing equi ed
pa ame e s. The la e es s he API agains common secu i y ulne abili ies issues,
such as SQL injec ion.
The execu ion scena ios gene a ed by Nominal Tes e , E o Tes e , and Secu i y
Tes e a e un in he REST ul-API-unde - es and i s esponses a e moni o ed o
spo he p esence o p og amming mis akes, e o s, and ulne abili ies. A se o
o acles a e de ined o his aim, which check esponses ac oss mul iple dimensions,
such as e o s a us code, da a consis ency wi h he OpenAPI speci ica ion, syn ax
and well- o med ou pu da a, aces o injec ion ulne abili ies.
In e es ing execu ion scena ios gene a ed by nominal, e o and secu i y es e s
a e ou pu as a se o es cases, consis ing o JSON desc ip ion o s eps and ja a
code using swagge codegen, o documen and ep oduce he issues.
OAu h/OIDC Tes ing
We also de eloped a ool o au oma ed OAu h/OIDC pene a ion es ing as a
plug-in o he Bu p Sui e, designed o be in eg a ed in ou secu i y aining and
pen- es ing en i onmen Mic o-ID-Gym [BCMOPR19]. Ou plug-in pe o ms
bo h passi e and ac i e es s o e he a ic gene a ed du ing an OIDC low.
Passi e es s do no in e e e wi h he low i sel bu analyze he eco ded a ic,
checking, o ins ance, s anda d compliance—whe he exchanged messages con-
o m o speci ica ions—and C oss-Si e Reques Fo ge y (CSRF) p o ec ion—e.g.,
by co ec implemen a ion o P oo Key o Code Exchange (PKCE). Ac i e es s
e i y he beha io o he endpoin s when subjec o unexpec ed, modi ied, o
emo ed inpu pa ame e s du ing he OAu h low.
The plug-in is buil on op o Bu p P oxy, a ool which allows es e s o
in e cep all eques s and esponses and le e ages he selenium-webd i e b owse
au oma ion lib a y. The inpu is a eco ded es ack, used as a guide o a sele-
nium ins ance. The ack con ains he ins uc ions o guide he selenium d i e
h ough an OAu h/OIDC low. The ack can be played back so ha a es e may
obse e whe he he b owse , con olled by he selenium d i e , is pe o ming as
expec ed. The ool is designed o pinpoin he s ep o he low in which inco ec
beha io has been sigh ed, and cou ses o ac ion o mi iga e agains i a e o be
in eg a ed.
Summa y
Ou p oposed app oach o TLS and API secu i y is one ha in eg a es he gen-
e a ion o ac ionable in elligence and o e s conc e e cou ses o ac ion o he
Re e ences 101
mi iga ion o ulne abili ies. Ou ongoing wo k includes he in eg a ion o TLSAs-
sis an in he FinSec pla o m, he iden i ica ion o compliance impac s o iden i ied
ulne abili ies, and models o con inuous isk assessmen . In u u e wo k, we aim
a ex ending API es ing wi h new pene a ion es ing unc ionali ies, bundle hem
o build a se o coope a ing secu i y se ices, and in eg a e he esul ing componen
in a sui able pla o m.
Acknowledgmen s
Black-box and whi e-box secu i y es s o REST API we e de eloped as pa o
Teîchos, an EIT Digi al Finance p ojec .
TLSAssis an was de eloped in a join lab wi h IPZS and is cu en ly being
enhanced and in eg a ed in FINSEC, a H2020 C i ical In as uc u e Inno a ion
Ac ion p ojec (Con ac Numbe : 786727), which is co- unded by he Eu opean
Commission in he scope o i s H2020 p og am.
Re e ences
[AFP13] N. J. Al Fa dan and K. G. Pa e son: “Lucky Thi een: B eaking he TLS
and DTLS Reco d P o ocols.” 2013 IEEE Symposium on Secu i y and P i-
acy, Be keley, CA, 2013, pp. 526–540, doi: 10.1109/SP.2013.42.
[BDLFPS14] K. Bha ga an, A. Deligna -La aud, C. Fou ne , A. Pi on i and P.
S ub: “T iple Handshakes and Cookie Cu e s: B eaking and Fixing Au hen-
ica ion o e TLS”. IEEE Symposium on Secu i y and P i acy 2014: 98–113.
[BCMOPR19] A. Bisegna, R. Ca bone, I. Ma ini, V. Odo izzi, G. Pellizza i and
S. Ranise: “Mic o-Id-Gym: Iden i y Managemen Wo kou s wi h Con aine -
Based Mic ose ices.” IJISC 8 (1), pp. 45–50, 2019.06.28.
[CVE-2019-16097] NIST Na ional Vulne abili y Da abase: Common Vulne a-
bili ies and Exposu es #2019-16097. URL: h ps://n d.nis .go / uln/de ail/
CVE-2019-16097
[EBA-OP-2018-7] “Opinion o he Eu opean Banking Au ho i y on he use o
eIDAS ce i ica es unde he RTS on SCA and CSC.” URL: h ps://eba.
eu opa.eu/ ile/58802/
[eIDAS] “Regula ion (EU) No. 910/2014 o he Eu opean Pa liamen and o
he Council o 23 July 2014 on elec onic iden i ica ion and us se ices
o elec onic ansac ions in he in e nal ma ke and epealing Di ec i e
1999/93/EC.” URL: h p://da a.eu opa.eu/eli/ eg/2014/910/oj
