Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

3/16/2008
09:51 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

The Clock Is Ticking For Retailer Web Application Security

In a few months time, what is now considered merely an advisable best practice will become mandatory for any business accepting credit card payments over the Web. Problem is, the mandate is ill conceived.

In a few months time, what is now considered merely an advisable best practice will become mandatory for any business accepting credit card payments over the Web. Problem is, the mandate is ill conceived.At the end of June, section 6.6 of the Payment Card Industry Data Security Standard (PCI DSS) goes into full effect. In short, this section of PCI DSS requires merchants and card payment providers to make certain their Web applications are secure.

If done right, it could actually help curb the number of Web-related security breaches.

But it's not done right. Not yet.

Here's section 6.6, which goes from a nice-to-do, to a must-do, on June 30:

Ensure that Web-facing applications are protected against known attacks by applying either of the following methods: -- Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security -- Installing an application layer firewall in front of Web-facing applications

Now, the overarching point of the PCI DSS is to both help instill a sense of trust among consumers in e-commerce, especially when it comes to online payments. And, hopefully, actually increase the Web security of online merchants, which until a couple of years ago remained ridiculously pathetic. Today, the state of retail security is just pathetic. So there's been some improvement.

In fact, the Privacy Rights Clearing House maintains a chronology of breaches here. It's a long list, and may take awhile for those with slower connections to load, so I don't recommend anyone using a dial-up connection to click the link. To date: 218 million data records have been exposed.

A few years ago, most of the breaches were caused by criminal hacking. Today, many breaches also are caused by the loss of laptops, thumb drives, and other forms of removable media. Yet, there's still a healthy number of criminal hacks, and sloppy Web and application design to go around.

And that's where section 6.6 steps in. And while I agree with the spirit of 6.6, which is better Web code, it's flawed as it's currently written.

It pretty much says that retailers can either perform a custom code assessment, or deploy a Web application firewall.

I'd much rather have PCI DSS mandate a security assessment be performed on all custom (as well as all commercial software before it's allowed to be shipped). Then, secondarily, advise the deployment of a Web application firewall.

As it stands now, retailers can build shoddy code, skimp on Q&A, and toss a Web application firewall in front of their ill-crafted code and claim compliance.

That's just not good enough.

And it's one of a long list of reasons why the list of breaches kept by the Privacy Rights Clearing House will continue to grow ... .

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
9 Tips to Prepare for the Future of Cloud & Network Security
Kelly Sheridan, Staff Editor, Dark Reading,  9/28/2020
Attacker Dwell Time: Ransomware's Most Important Metric
Ricardo Villadiego, Founder and CEO of Lumu,  9/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20902
PUBLISHED: 2020-10-01
Upgrading Crowd via XML Data Transfer can reactivate a disabled user from OpenLDAP. The affected versions are from before version 3.4.6 and from 3.5.0 before 3.5.1.
CVE-2019-20903
PUBLISHED: 2020-10-01
The hyperlinks functionality in atlaskit/editor-core in before version 113.1.5 allows remote attackers to inject arbitrary HTML or JavaScript via a Cross-Site Scripting (XSS) vulnerability in link targets.
CVE-2020-25288
PUBLISHED: 2020-09-30
An issue was discovered in MantisBT before 2.24.3. When editing an Issue in a Project where a Custom Field with a crafted Regular Expression property is used, improper escaping of the corresponding form input's pattern attribute allows HTML injection and, if CSP settings permit, execution of arbitra...
CVE-2020-25781
PUBLISHED: 2020-09-30
An issue was discovered in file_download.php in MantisBT before 2.24.3. Users without access to view private issue notes are able to download the (supposedly private) attachments linked to these notes by accessing the corresponding file download URL directly.
CVE-2020-25830
PUBLISHED: 2020-09-30
An issue was discovered in MantisBT before 2.24.3. Improper escaping of a custom field's name allows an attacker to inject HTML and, if CSP settings permit, achieve execution of arbitrary JavaScript when attempting to update said custom field via bug_actiongroup_page.php.