OWASP Vulnerability #8 – Cross-Site Request Forgery (CSRF)

 

Computer crime concept.Continuing with the discussion of the OWASP Top 10 Web Vulnerabilities, this post will look at number 8: cross-site request forgery. This particular vulnerability is difficult for many people to understand, but can be quite common in web applications. Because of its prevalence, Clearent has had to digest and understand this vulnerability in order to build a secure, PCI-compliant payments platform.

What is Cross-Site Request Forgery?

Cross-Site Request Forgery (CSRF) is a vulnerability where a website accepts requests from an agent that were not originated by an authorized user. This attack is best understood with an example. Let’s say a user is logged into their bank’s online banking website and while authenticated, the user visits another site by creating a new tab in the browser. The other site visited has a hidden link that sends a request to the user’s bank, initiating a transfer request to a bad guy’s bank account. The malicious request uses the cookies and session data of the authenticated user in the request, allowing the request to succeed. In this example, the bank site is susceptible to a Cross-Site Request Forgery. Read more

WordCamp St. Louis & Taking Payments Using Clearent’s WordPress Payments Plug-in

WordCamp 2016

So what kind of work do you do? I asked this open-ended question to every WordCamp St. Louis attendee who stopped by Clearent’s table last weekend at Washington University. I borrowed the conversation starter from my colleague Andrew Bell (pictured left with developer Jill Willard). I liked how people visibly opened up by relaxing their shoulders when they heard it. Like they were honored to talk about their work, because it meant they could talk about their passion rather than just their job title and company name.

As you can imagine, I heard some interesting responses. This was a WordCamp St. Louis event after all! I met a mini bike distributor, an author, and even a nut milk start-up. The other group of people I met were full-time and freelance web designers and web developers. All were using WordPress as a conduit to market their passions—whether it was for themselves or for their clients. And they all needed a way to accept payments. Read more

EMV: A Multitude of Payment Solutions

Clearent Payments API

What is EMV?  EMV, by definition, “is a global standard for credit and debit payment cards based on chip card technology taking its name from the card brands Europay, MasterCard, and Visa – the original card brands that developed it.” That definition doesn’t tell us much. Most of us understand EMV to mean chip cards that can be inserted into a slot in the payment terminal. Chip cards allow additional verification to prevent fraud in card-present transactions. They are much harder to copy than the traditional magstripe.  They also have additional verification built into each transaction so that each use can’t be reused, like magstripes can be.

EMV has disrupted the industry because as of October 2016 the Card Brands (MasterCard, Visa, Discover and Amex) have required their merchants to either accept EMV chip cards, or be responsible for additional fraud liability. This has been referred to as the liability shift. This liability shift has rattled the payments industry. It’s the first time in years that U.S. merchants will be forced to upgrade their point-of-sale (POS) equipment and terminals. Vendors of terminals are scrambling to support the technology and grab more market share; merchants that are forced to buy new equipment start looking at new vendors. Read more

PCI Check Up

Clearent PCI

At Clearent, we are starting preparations for our annual PCI audit.  One of the components of the PCI audit is ensuring that web applications guard against the OWASP Top 10 Web Application Vulnerabilities.  I thought this would be a good time to review that list.

The OWASP.org_PDF is the best source of information if you are creating web applications.  Below is a listing of the 10 vulnerabilities and a brief explanation of them.

Top Ten Web Application Vulnerabilities:

  1. Injection: This vulnerability covers all kinds of injection attacks, including SQL injection.  Applications need to ensure that user-entered data can’t modify execution paths of the application itself.  It is important to guard against data coming into the application, as well as data being retrieved by the application.
  2. Broken Authentication and Session Management: Quite often developers create all of their application’s functionality themselves, and introduce bugs.  Authentication and Session management are no different.  If possible, use tried-and-true third party applications to handle these functions.
  3. Cross-Site Scripting (XSS): XSS is a nasty vulnerability that typically hijacks a user’s browser to access a malicious website or to steal data.  Applications generally protect against this flaw by properly escaping data entered through the browser.
  4. Insecure Direct Object References: This vulnerability typically happens when a developer exposes file names, unique identifiers or other “internal” data that would allow an attacker to directly manipulate the system, bypassing data validation checks.
  5. Security Misconfiguration: Not locking down systems, changing default passwords, or keeping software up-to-date causes this vulnerability.  All of these things seem obvious, but if they are obvious to us, they are obvious to attackers as well.
    Read more

Integrating Payments into a Spring Boot Service

RESTful Interface Flow

This is a quick tutorial showing how easy it is to integrate with Clearent’s secure payments gateway. Clearent has designed a language agnostic RESTful online payments gateway, meaning developers of almost any language should be able to start processing with Clearent.

Today we’ll be using Spring Boot and a handful of other libraries to get a payments service up and running fast. Spring Boot provides an opinionated implementation of the Spring framework in an embedded JAR file. We’ve been using it internally here at Clearent for over a year now, and has reduced our development time and has provided quick integration with thousands of popular libraries and tools. We’re going to assume some basic familiarity with Spring Boot, but if you’d like an introduction, Spring’s Tutorial on Building REST Services demonstrates all of the topics covered in this post.

Read more

Distributed Systems for Clearent Payments

Distributed systems is an area of computing that attempts to address the problems some companies have with scaling computer resources once they grow beyond what one machine can handle.  Issues of scale can appear when the number of users, amount of data, or computation requirements grows to a level in which one machine, however large, is incapable of meeting service demands.  For some companies, the amount of data that is required to be online and accessible for reporting or research is so massive that a single database or filesystem cannot store it.  Other companies that handle requests on-demand from users via an API or hosted service find that the number of requests made within a period of time has grown to a point where the system cannot react to every request in a timely fashion.   Computation in some industries can be so large or intense that if one machine is asked to perform it would take so long that the results of the computation are irrelevant by the time it is complete.

 

At Clearent we use techniques from distributed systems to help level out the time it takes to process batch transactions as our merchant base grows.  Our backend system receives transactions numerous times each day in large data dumps.  Our desire to help merchants get their funds the next day and strict bank funding windows puts pressure on our system to qualify, bill, and settle all transactions within limited timeframes despite the fact that our transaction volume continually increases.  We therefore parallelize the processing of transactions across a network of machines, configured to coordinate and ensure exactly-once transaction processing.  In the event that our system cannot meet the timeliness demands of our partners we can add new processing nodes to bring the completion time back down to acceptable levels.

Read more