<Clearent Developer Blog/>

OWASP Vulnerability #6 – Sensitive Data Exposure

Payments System Hacking. Online Credit Cards Payment Security Concept. Hacker in Black Gloves Hacking the System.

Number 6 on the OWASP Top 10 List is Sensitive Data Exposure.  This vulnerability occurs when data that should not be seen, such as credit card numbers, tax ID numbers, passwords, and social security numbers becomes exposed.  At Clearent, we pay close attention to this issue and work hard to ensure that our data is protected within our payments platform.

Intuitively, developers understand that data elements like credit card numbers and tax ID numbers need to be protected.  What they don’t always know, however, is how to protect that data.  It’s fairly obvious to realize the need to encrypt sensitive data or store it on encrypted hard disks.  What isn’t so obvious is the need for precautions for the mechanisms that transfer the sensitive data. And because many people don’t realize the need for this, it makes it possible to get their data by monitoring network traffic.  To this point, many of the recent payment breaches were accomplished by monitoring unencrypted network traffic inside a system. Read more

OWASP Vulnerability #7 – Missing Function Level Access Control

Rear view of young man typing and looking at computer monitor while sitting at the table in dark room

The next vulnerability to look at from the OWASP Top 10 List of Web Vulnerabilities is #7, Missing Function Level Access Control.  This vulnerability is easy to understand, but is important to acknowledge because of its abundance in web applications.  At Clearent, we have always paid close attention to function level access control because it is a critical element of the reporting and administration of our payments platform.

Applications that have missing function level access control allow an end user to simply enter a given URL or manually call a function that shouldn’t be exposed to them in order to access data or functionality that has not been explicitly assigned.  Sometimes this vulnerability is manifested by data or application navigation becoming exposed to a user that shouldn’t see it, but more often it is manifested by not performing a security check on individual function calls.  One of the easiest ways to test for this vulnerability is to log into an application as a user with restricted privileges, then type in the URL of a resource that requires more privilege, and see what happens.  If the restricted resource is brought up, the application has this vulnerability.  If not, the application is most likely doing the right things.

Read more

.NET Garbage Collection

blog garbageIn an unmanaged runtime, such as C or C++, you allocate and free up memory for your application through code. A managed runtime, on the other hand, typically has a process governor that manages memory for your application so that you don’t have to. The mechanism that does this is usually referred to as the garbage collector. The .NET runtime has a configurable garbage collector that usually does just fine without software developers caring very much about it. Normally, it just works and does a very good job of managing memory for your app. It can be important, however, to understand how the garbage collector works at times, even if you never need to change the way it operates.

.NET Garbage Collection Basics

The garbage collector is invoked by the runtime to clean up unused memory and defragment the heap generally whenever the application feels pressure to do so. While you can request that garbage collection happen at specific points in your app, you cannot explicitly start garbage collection yourself. And, that being said, it is generally frowned upon to make calls to GC.Collect(). Read more

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

Using Continuous Delivery for Our Online Payment Gateway

edited quoteOver the last few months at Clearent we’ve been rolling out new features like crazy, and have launched a handful of exciting new products to our online payment gateway. But, with the pace at which we’re developing new technology, we’re realizing one of our biggest pain points–our release process. We often look to the industry leaders to seek guidance, and one of the software development leaders that we look to is Martin Fowler. His favorite soundbite is “if it hurts, do it more often.” It essentially means to do painful things more frequently so that they eventually become less painful. What we needed was a way to reduce the pain associated with releases. So we’ve made big strides towards implementing continuous delivery for our development team.

What is continuous delivery?

As we’ve been building out our online payment gateway, we’ve been talking about this topic a lot. The basic concept is that every time a developer commits a new feature to our codebase, we take that and create a deliverable product. We want to automate our process of building our code, running our tests, staging our environments, and promoting our products to our higher environments. 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

Using Feature Switches for Code


Using feature switches fore code development is a technique used by software developers or DevOps professionals to turn portions of code on or off without requiring a rebuild of the application.  There can be many reasons for using this technique. Often, a feature may need to be released but is in the same build as a feature that cannot be released.  In other cases important code releases require customer notification that may not have happened yet.  Releasing the code with the ability to turn certain features off can clear it as a work item for the IT team while leaving the business with the flexibility to release the feature at a later date.

Feature switches for the Clearent back end development team typically come in two parts: a configuration setting indicating the state of the feature and a dependency swap or IF statement to switch the behavior out based on the configuration setting.  Here is a simple example of what a feature switch could look like:

Read more

OWASP Security Vulnerability #9 – Components with Vulnerabilities

Developer Cyber Security PCI

This post is a continuation from my first Developer Blog post “PCI Check Up” – outlining the OWASP Top 10 web security vulnerabilities.  We keep these security vulnerabilities in mind as we build out our own payments platform and provide integration points to our partner developers.  In this post, I will review the number 9 OWASP web security vulnerability.

The number 9 vulnerability is Using Components with Known Vulnerabilities.  Most modern web applications take advantage of third-party libraries or frameworks that facilitate application development.  If those third-party components have vulnerabilities in them, then by extension any application that uses those components have security vulnerabilities.  It seems fairly obvious, but many developers simply lose site of this concern.

Read more

OWASP Security Vulnerability #10 – Unvalidated Redirects and Forwards

Payment Security PCI

In a previous post ”Developer PCI Check up”, I provided a high-level overview of the OWASP (Open Web Application Security Project) Top 10 web security vulnerabilities.  Ensuring that these security vulnerabilities don’t exist in a web application is a critical part of being PCI compliant.  This is the first of ten posts going into more detail on each of the vulnerabilities.

Number 10 on the list is Unvalidated Redirects and Forwards.  Quite often, modern web applications use HTTP redirects and forwards to control the flow of their application.  A vulnerable system can be used to redirect users to malicious sites or to download malicious code.  A system may be vulnerable if it uses query string parameters passed in the URL to redirect their application.  Here is an example of a URL that is vulnerable:

Read more