[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [WEB SECURITY] Cross-Site Scripting PCI Question
- From: Trey Ford <ford.trey@xxxxxxxxx>
- Subject: Re: [WEB SECURITY] Cross-Site Scripting PCI Question
- Date: Wed, 4 Mar 2009 14:03:17 -0800
--0016364ef40a1216f60464523872
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Joe,
You have framed a couple of really good questions here:
1) Will a website vulnerability prevent a company from achieving PCI
compliance?
Remember the difference between validation and compliance. PCI validation
is what happens during the audit. Picture the moment where you hand your
insurance to a police officer during a routine traffic stop. That is
validation, the point in time where you are verifying the proof of
insurance.
Compliance is maintaining that secured state all of the time, not just
during PCI validation. (just having your 'proof of insurance' card for a
cancelled policy means you might sneak past validation, but you certainly
are not compliant, right?)
Another example would be applying your Windows service packs. If Microsoft
releases a patch the night before the auditor shows up, there is no way tha=
t
patch gets applied in time to be 'validated'. That patch must go through
testing, limited deployment, and then enterprise wide deployment. That
doesn't mean you aren't compliant, but you better be getting that patch
deployed!
Continually identifying website vulnerabilities is only part of the battle.
A well run PCI Audit will probably be focused on ensuring the website
security program is performing up to expectations established in the PCI
standard. It hopefully won't come down to 'we found a vulnerability, so yo=
u
fail.' (get a good PCI Qualified Security Auditor, ask for references or
referrals)
2) Will a non-credit card related website be considered 'in scope' for PCI
compliance?
If www.example.com, shopping.example.com, or blogs.example.com has the
ability to weaken the security of your payment.example.com application-
they are absolutely in scope.
Relationships to explore and test against will include Same Origin Policy
and crossdomain.xml for starters.
3) Can a vulnerability in a non-payment website affect the security of the
payment website?
Absolutely. Assaulting the payments site from one of the others with Cookie
Theft, CSRF, and other fun attacks come to mind.
4) Can a vulnerability in the non-payment website affect the compliant stat=
e
of the payment website?
Yes. FWIW, attackers look for and explore edge cases. If you have a poorl=
y
secured blogs.x or shopping.x that allows the 'bad guys' options for attack=
,
why would they waste a bunch of time on a highly tested and secured payment=
s
website?
Obvious sites like https://payment.example.com are often well tested, the
other 'ignored' sites can create or expand the attack surface against more
valued sites. Organizations often have massive volumes of unknown
vulnerabilities in sites they don't see value in testing.
Website security is challenging. Building and maintaining a well balanced
website security program is the key to making compliance a no-brainer.
Keep an inventory of all of your websites.
Know who 'owns' those sites, who is responsible for them.
Place a value on those websites. A priority of sorts. Some will have a
regulatory impact (like PCI), others are valued due to revenue.
Test the websites. All of 'em. Test the more valuable sites more
carefully, but don't ignore the little ones. You cannot afford it.
Distribute the findings, communicate the risk, make business decisions on
what to do.
Track and measure the success of the program.
Repeat!
Great question, thanks for the post! (for those going to InfoSec World in
Orlando, we will be covering this stuff in depth in a PCI Website Security
workshop... see you there!)
~trey
http://treyford.wordpress.com
On Wed, Mar 4, 2009 at 11:50 AM, Joe Hargrove <ae31337@gmail.com> wrote:
> Let=92s say that we have a website that consists of many different
> subdomains, like this:
>
>
>
> http://www.example.com
>
> http://blogs.example.com
>
> http://shopping.example.com
>
> https://payment.example.com
>
>
>
> All of the pages that take credit card information as input are hosted
> under the payment.example.com subdomain. Would XSS vulnerabilities on
> pages within the first 3 subdomains be issues that would/should cause the
> company to fail a PCI compliance audit?
>
On Wed, Mar 4, 2009 at 11:50 AM, Joe Hargrove <ae31337@gmail.com> wrote:
> Let=92s say that we have a website that consists of many different
> subdomains, like this:
>
>
>
> http://www.example.com
>
> http://blogs.example.com
>
> http://shopping.example.com
>
> https://payment.example.com
>
>
>
> All of the pages that take credit card information as input are hosted
> under the payment.example.com subdomain. Would XSS vulnerabilities on
> pages within the first 3 subdomains be issues that would/should cause the
> company to fail a PCI compliance audit?
>
>
--0016364ef40a1216f60464523872
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div class=3D"im">Joe,<div><br></div><div>You have framed a couple of reall=
y good questions here:</div><div><br></div><div><span style=3D"font-weight:=
bold; "><span style=3D"text-decoration: underline; ">1) Will a website vul=
nerability prevent a company from achieving PCI compliance?</span></span></=
div>
<div>Remember the difference between validation and compliance. =A0PCI vali=
dation is what happens during the audit. =A0Picture the moment where you ha=
nd your insurance to a police officer during a routine traffic stop. =A0Tha=
t is validation, the point in time where you are verifying the proof of ins=
urance. =A0</div>
<div><br></div><div>Compliance is maintaining that secured state all of the=
time, not just during PCI validation. =A0(just having your 'proof of i=
nsurance' card for a cancelled policy means you might sneak past valida=
tion, but you certainly are not compliant, right?)</div>
<div><br></div></div><div>Another example would be applying your Windows se=
rvice packs. =A0If Microsoft releases a patch the night before the auditor =
shows up, there is no way that patch gets applied in time to be 'valida=
ted'. =A0That patch must go through testing, limited deployment, and th=
en enterprise wide deployment. =A0That doesn't mean you aren't comp=
liant, but you better be getting that patch deployed!</div>
<div class=3D"im"><div><br></div><div>Continually identifying website vulne=
rabilities is only part of the battle. =A0</div><div><br></div><div>A well =
run PCI Audit will probably be focused on ensuring the website security pro=
gram is performing up to expectations established in the PCI standard. =A0I=
t hopefully won't come down to 'we found a vulnerability, so you fa=
il.' (get a good PCI Qualified Security Auditor, ask for references or =
referrals)</div>
<div><br></div><div><span style=3D"font-weight: bold; "><span style=3D"text=
-decoration: underline; ">2) Will a non-credit card related website be cons=
idered 'in scope' for PCI compliance?</span></span></div><div>If=A0=
<a href=3D"http://www.example.com"; target=3D"_blank">www.example.com</a>,=
=A0<a href=3D"http://shopping.example.com"; target=3D"_blank">shopping.examp=
le.com</a>, or=A0<a href=3D"http://blogs.example.com"; target=3D"_blank">blo=
gs.example.com</a>=A0has the ability to weaken the security of your =A0<a h=
ref=3D"http://payment.example.com"; target=3D"_blank">payment.example.com</a=
>=A0application- they are absolutely in scope.</div>
<div><br></div><div>Relationships to explore and test against will include =
Same Origin Policy and crossdomain.xml for starters.</div><div><br></div><d=
iv><span style=3D"font-weight: bold; "><span style=3D"text-decoration: unde=
rline; ">3) Can a vulnerability in a non-payment website affect the securit=
y of the payment website?</span></span></div>
<div>Absolutely. Assaulting the payments site from one of the others with C=
ookie Theft, CSRF, and other fun attacks come to mind.</div><div><br></div>=
<div><span style=3D"text-decoration: underline; "><span style=3D"font-weigh=
t: bold; ">4) Can a vulnerability in the non-payment website affect the com=
pliant state of the payment website?</span></span></div>
<div>Yes. =A0FWIW, attackers look for and explore edge cases. =A0If you hav=
e a poorly secured blogs.x or shopping.x that allows the 'bad guys'=
options for attack, why would they waste a bunch of time on a highly teste=
d and secured payments website?</div>
<div><br></div><div>Obvious sites like=A0<a href=3D"https://payment.example=
.com" target=3D"_blank">https://payment.example.com</a>=A0are often well te=
sted, the other 'ignored' sites=A0can create or expand the attack s=
urface against more valued sites. =A0Organizations often have massive volum=
es of unknown vulnerabilities in sites they don't see value in testing.=
</div>
<div><br></div><div>Website security is challenging. =A0Building and mainta=
ining a well balanced website security program is the key to making complia=
nce a no-brainer.</div><div><br></div><div><span class=3D"Apple-style-span"=
style=3D"font-weight: bold; "><span class=3D"Apple-style-span" style=3D"te=
xt-decoration: underline; -webkit-text-decorations-in-effect: underline; ">=
Keep an inventory</span></span>=A0of all of your websites.</div>
<div><span class=3D"Apple-style-span" style=3D"font-weight: bold; "><span c=
lass=3D"Apple-style-span" style=3D"text-decoration: underline; -webkit-text=
-decorations-in-effect: underline; ">Know who 'owns' those sites</s=
pan></span>, who is responsible for them.</div>
<div><span class=3D"Apple-style-span" style=3D"font-weight: bold; "><span c=
lass=3D"Apple-style-span" style=3D"text-decoration: underline; -webkit-text=
-decorations-in-effect: underline; ">Place a value</span></span>=A0on those=
websites. =A0A priority of sorts. Some will have a regulatory impact (like=
PCI), others are valued due to revenue.</div>
<div><span class=3D"Apple-style-span" style=3D"text-decoration: underline; =
-webkit-text-decorations-in-effect: underline; "><span class=3D"Apple-style=
-span" style=3D"font-weight: bold; ">Test the websites. =A0All of 'em</=
span></span>. =A0Test the more valuable sites more carefully, but don't=
ignore the little ones. =A0You cannot afford it.</div>
<div><span class=3D"Apple-style-span" style=3D"font-weight: bold; "><span c=
lass=3D"Apple-style-span" style=3D"text-decoration: underline; -webkit-text=
-decorations-in-effect: underline; ">Distribute the findings</span></span>,=
communicate the risk, make business decisions on what to do.</div>
<div><span class=3D"Apple-style-span" style=3D"text-decoration: underline; =
-webkit-text-decorations-in-effect: underline; "><span class=3D"Apple-style=
-span" style=3D"font-weight: bold; ">Track and measure</span></span>=A0the =
success of the program.</div>
<div><span class=3D"Apple-style-span" style=3D"font-weight: bold; "><span c=
lass=3D"Apple-style-span" style=3D"text-decoration: underline; -webkit-text=
-decorations-in-effect: underline; ">Repeat!</span></span></div><div><br></=
div>
<div>Great question, thanks for the post! =A0(for those going to InfoSec Wo=
rld in Orlando, we will be covering this stuff in depth in a PCI Website Se=
curity workshop... see you there!)</div><div><br></div><div>~trey</div><div=
>
<a href=3D"http://treyford.wordpress.com"; target=3D"_blank">http://treyford=
.wordpress.com</a></div><div><div></div><div><div><br><div class=3D"gmail_q=
uote">On Wed, Mar 4, 2009 at 11:50 AM, Joe Hargrove=A0<span dir=3D"ltr"><=
;<a href=3D"mailto:ae31337@gmail.com"; target=3D"_blank">ae31337@gmail.com</=
a>></span>=A0wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0=
px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-=
left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex=
; ">
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size: 10pt; font-fam=
ily: Arial; ">Let=92s say that we have a website that consists of many diff=
erent subdomains, like this:</span></font></p><p><font size=3D"2" face=3D"A=
rial"><span style=3D"font-size: 10pt; font-family: Arial; ">=A0</span></fon=
t></p>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size: 10pt; font-fam=
ily: Arial; "><a href=3D"http://www.example.com"; target=3D"_blank">http://w=
ww.example.com</a></span></font></p><p><font size=3D"2" face=3D"Arial"><spa=
n style=3D"font-size: 10pt; font-family: Arial; "><a href=3D"http://blogs.e=
xample.com" target=3D"_blank">http://blogs.example.com</a></span></font></p=
>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size: 10pt; font-fam=
ily: Arial; "><a href=3D"http://shopping.example.com"; target=3D"_blank">htt=
p://shopping.example.com</a></span></font></p><p><font size=3D"2" face=3D"A=
rial"><span style=3D"font-size: 10pt; font-family: Arial; "><a href=3D"http=
s://payment.example.com" target=3D"_blank">https://payment.example.com</a><=
/span></font></p>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size: 10pt; font-fam=
ily: Arial; ">=A0</span></font></p><p><font size=3D"2" face=3D"Arial"><span=
style=3D"font-size: 10pt; font-family: Arial; ">All of the pages that take=
credit card information as input are hosted under the=A0<a href=3D"http://=
payment.example.com" target=3D"_blank">payment.example.com</a>=A0subdomain.=
<span>=A0=A0</span>Would XSS vulnerabilities on pages within the first 3 su=
bdomains be issues that would/should cause the company to fail a PCI compli=
ance audit?</span></font></p>
</blockquote></div></div></div></div></div><br><div class=3D"gmail_quote">O=
n Wed, Mar 4, 2009 at 11:50 AM, Joe Hargrove <span dir=3D"ltr"><<a href=
=3D"mailto:ae31337@gmail.com";>ae31337@gmail.com</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex;">
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size:10pt;font-famil=
y:Arial">Let=92s say that we have a website that consists of many
different subdomains, like this:</span></font></p>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size:10pt;font-famil=
y:Arial">=A0</span></font></p>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size:10pt;font-famil=
y:Arial"><a href=3D"http://www.example.com"; target=3D"_blank">http://www.ex=
ample.com</a></span></font></p>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size:10pt;font-famil=
y:Arial"><a href=3D"http://blogs.example.com"; target=3D"_blank">http://blog=
s.example.com</a> </span></font></p>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size:10pt;font-famil=
y:Arial"><a href=3D"http://shopping.example.com"; target=3D"_blank">http://s=
hopping.example.com</a></span></font></p>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size:10pt;font-famil=
y:Arial"><a href=3D"https://payment.example.com"; target=3D"_blank">https://=
payment.example.com</a></span></font></p>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size:10pt;font-famil=
y:Arial">=A0</span></font></p>
<p><font size=3D"2" face=3D"Arial"><span style=3D"font-size:10pt;font-famil=
y:Arial">All of the pages that take credit card information as input
are hosted under the <a href=3D"http://payment.example.com"; target=3D"_blan=
k">payment.example.com</a> subdomain.<span>=A0 </span>Would XSS vulnerabili=
ties on
pages within the first 3 subdomains be issues that would/should cause the c=
ompany
to fail a PCI compliance audit?</span></font></p><p></p>
</blockquote></div><br>
--0016364ef40a1216f60464523872--
Brought to you by http://www.webappsec.org
Search this site
|