SQL Operations Studio on Mac

Microsoft recently released SQL Operations Studio for the Mac. It is a SQL Server management tool based on VS Code. I was lukewarm about this release because I use a Mac that is not associated with our domain and the SQL Servers I interact with don't have SQL Login enabled. After a little internet searching (i.e. Google), I found that I could issue Kerberos tickets via the command line and authenticate to Windows domain resources with Windows Authentication. Woo Hoo!

Unfortunately, this didn't work when I tried it. I was able to issue the Kerberos ticket using the instructions below, but SQL Operations Studio would not proerly authenticate. After a little more internet searching (i.e. Google again), I found this issue on Github. One of the comments on the issue recommended using all caps for the information entered in the command to issue the Kerberos ticket. That tidbit is exactly what was needed. I can now access SQL Servers using Windows Authentication using SQL Operations Studio on my Mac!

Instructions for Using Windows Authentication with SQL Operations Studio

1. Open a terminal window.
2. Type the following command:

   kinit USERNAME@DOMAIN.COM

3. Ensure the command issued above uses all caps for the domain information.
4. Open SQL Operations Studio.
5. Connect to a database using Windows Authentication.
6. Enjoy!

Find a File with Certain Contents

I was trying to search for a file with a particular class name inside it, and I could not remember the syntax of the command to save my life.  I knew I had it in a note somewhere, but I couldn't find that either.

Tonight I found the note.  I'm posting the command here so I can find it again.

For linux:
find . -name 'filepattern' -exec grep -l 'contentpattern' {} \;
For Powershell:
Get-ChildItem -Recurse | Select-String "dummy" -List | Select Path

Running Apps in Docker for Mac

In an earlier post I wrote instructions for running graphical applications out of Docker containers on my Mac. Since I wrote that post, I have wiped my Mac and reinstalled everything, including Docker for Mac. This post is an update of those instructions.

The steps for running graphical applications from Docker on a Mac have simplified quite a bit. These instructions assume you have Docker for Mac installed and running and have access to container images. Without further ado, here are the instructions:

1. Install XQuartz from https://www.xquartz.org/. This MUST be done. The separate installation is required for the graphical applications to run on the Mac host from a Docker container.
2. Logout and log back into the Mac. This is necessary to use XQuartz.
3. Open XQuartz. From a terminal, execute the following command:

   open -a XQuartz

4. In the XQuartz terminal window, execute the command:

   xhost +

   This command may be a little insecure; I haven't researched it fully yet.
5. Run your Docker container, passing the DISPLAY environment variable with a command like:

   docker run --rm -it -e DISPLAY=192.168.1.1:0 ubuntu:latest /bin/bash

   192.168.1.1 is a sample IP address. Use the IP address of your system there.
6. Within the Docker container, run an application with a graphical interface. This should display on the Mac.
7. Enjoy!

Skills Atrophy

This morning at the Gateway to Innovation Conference in St. Louis, Scott McNealy of Sun Microsystems fame gave the keynote presentation. One of the points he hammered home was a fact where he stated that an IT person loses 20% of their skills per year. This theme was repeated by other conference speakers as well.

If this statistic is true, I'm not worried about it. At Clearent, two of our cultural tenets have us prepared: make others great and continuous learning.

Making others great keeps us focused on lifting people up and sharing what we know. This ensures that as the tide rises (people learn new skills), all boats get lifted (everyone has an opportunity to learn new things).

The other tenet of continuous learning is a bit obvious. What is not obvious is that Clearent has a training budget, and the IT management is measured based on everyone in IT going to training! The organizational focus ensures that training and new ideas are infused into the organization.

If Scott's claim about skill atrophy is correct, Clearent is in a great position to lead the technological pack!

Working with Files in Bash

I always forget how to loop through files in a Bash shell. Below are two snippets for looping through files using Bash.

Using a FOR loop in a script.

for file in $(command for files); do
    echo $file
done

Single line command.

find . -name "file glob" -exec command '{}' \;

OWASP Vulnerability #9

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.

A high-profile example of this kind of vulnerability was the Heartbleed bug in the OpenSSL library.  When this vulnerability was announced, many and various applications became vulnerable because they included the OpenSSL library.  Heartbleed is a severe vulnerability that was highly publicized, but the same thing can happen with other software components.

Mitigating this vulnerability is straightforward, but not something most developers care to do.  The basic tasks necessary to mitigate this vulnerability are:

1. Identify all third-party libraries, frameworks, and components in use in your application. It is also important to track the versions of these packages that are in use.
2. Monitor the security of the components in use in your application. There are several sites and services that publish vulnerabilities.  I follow www.us-cert.gov and www.sans.org.  (Both of these sites provide published bulletins that make it easier to keep up with vulnerabilities.)
3. When security vulnerabilities are discovered, first understand how the software provider is addressing the flaw. Next, you need to incorporate any fix from the vendor you’re your application.  This is usually done by upgrading the affected component.
4. Sometimes it is necessary to establish policies and conventions around what third-party components can be used in your application. These policies may include accepted vendors or certification requirements for third-party libraries.

Of the OWASP Top 10 list, this is not the most technical vulnerability, but it is easy to address.

Software Developer Career Progression

Career development for software developers is a tricky subject. Most people start their career in a job with a title similar Junior Programmer or Software Engineer I. If this person is lucky, the company has a few next steps defined such as Senior Programmer or Software Engineer II. Unfortunately there is no definition of what is required to be a "senior" programmer or what it takes to achieve Software Engineer II. There is also no correlation between one company's Senior Programmer and another company's Software Engineer III.

At Clearent, we created "developer levels." These levels are gradients through a software developer career lifecycle. We have defined 10 levels that we can use to talk about an individual's career progression. The first 5 levels are focused on gaining individual skills. The second 5 levels are focused on making others great. The rationale for this is that early in one's career, it is important to learn and grow and build a skill set. As a developer advances, it is more important if that developer can help others to grow than master some new skill.

None of the items listed in the levels is a hard-and-fast requirement, but each item points to a type of activity that is necessary. For instance, many levels require an individual to host a lunch-and-learn, code review, or create a wiki document. This activity is meant to push a developer to share knowledge with a broader group. All of these items can be customized for an individual at a manager's discretion.

The levels that we are using are:

Level1
	Complete the basic katas
	Complete a tour of duty on Prod Support
	Describe the purpose behind our retrospectives
	Explain why TDD is important
	Have code deployed to production
	Host a code review
Level2
	Complete the intermediate katas
	Demonstrate knowledge of a particular business process
	Be able to list at least 4 of Top 10 OWASP Web Vulnerabilities
	Host a lunch-and-learn or code review
	At least one additional of lunch-and-learn, code review, wiki article
Level 3
	One year anniversary
	Host a lunch-and-learn or code review
	Be able to articulate and explain each of the SOLID principles
	Complete the advanced katas
	Explain the primary business model
	At least one additional of lunch-and-learn, code review, wiki article
Level 4
	Write at least one article for the Wiki
	Take part in a candidate phone screen
	Create a tech blog and write at least one article a month for a year
	Be able to draw a picture of the architecture of the major applications in our system
	At least one additional of lunch-and-learn, code review, wiki article
Level 5
	Two-year anniversary
	Host a lunch-and-learn on a tech topic new to the company
	Lead an initiative and see it to completion
	Create 2 new basic katas for the kata library
	Be the lead on a business process
	At least one additional of lunch-and-learn, code review, wiki article
Level 6
	Locate 5 patterns from the GOF book being used in our code.  Describe our use of them.  Was it correct?
	Teach another member of the team something new.  They should be able to talk intelligently about the topic to a level 6 dev.
	Create 2 new intermediate katas for the kata library
	Take part in the in-person interview of a developer candidate.
	At least two additional of lunch-and-learn, code review, wiki article
Level 7
	Present a topic at a developer-focused conference or user group
	Create a github account and commit to an open source project once per month for a year.  (May be your own project as long as it is public)
	Three-year anniversary
	Demonstrate the ability to communicate complex technical topics to non-technical people
	At least two additional of lunch-and-learn, code review, wiki article
Level 8
	Contribute a pull request to an open source project on github with more than 20 contributors.  The pull request must be accepted.
	Pair with an intern or new developer their first two weeks of work.
	Create 2 new advanced katas for the kata library
	Complete a version of the basic katas in a language you are not familiar with.  (The katas may not port exactly, so be creative.)
	At least three additional of lunch-and-learn, code review, wiki article
Level 9
	Five-year anniversary
	Complete a version of the intermediate and advanced katas in the language you picked for the task in level 8.
	Write a recommendation for another developer whom you value and respect.  They need not be on this team.
	Complete a version of the basic katas in yet another language that you are not familiar with.
	Demonstrate the ability to lead a project to completion and coordinate with outside parties
	At least three additional of lunch-and-learn, code review, wiki article
Level 10
	Dream up and implement a tool, product, or enhancement to an existing application that, upon completion, adds to the company's financial bottom line.
	Demonstrate the ability to be a team lead and mentor for both interpersonal and technological development.
	At least three additional of lunch-and-learn, code review, wiki article

Hopefully this helps others to think about developer career progression in new ways.

OWASP Top 10 Vulnerabilities Review

This article was originally posted at the Clearent Developer Blog.

My company, Clearent, is subject to an annual PCI audit. A part of that audit is being secure 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.
6. Sensitive Data Exposure: Simply put, many applications expose things like credit card numbers and tax IDs.  This information must be closely guarded.
7. Missing Function Level Access Control: Applications should ensure that an action a user takes in a web application is one the user has been granted access to.  This check should occur in the web application and on the server side portion of the application as well.
8. Cross-Site Request Forgery (CSRF): This attack uses a user’s browser to submit requests on the user’s behalf without the user being aware of it.  Application frameworks are getting smarter about this vulnerability and make it easy for developers to thwart this attack.
9. Using Components with Known Vulnerabilities: Many applications utilize external frameworks, libraries, or applications.  Care needs to be taken to ensure these third-party packages don’t have flaws that can be exploited.
10. Unvalidated Redirects and Forwards: It is common to use HTTP redirects and forwards to control the flow of an application.  These redirects and forwards can be used to send a user to a malicious site and cause harm.

This listing is not an exhaustive explanation of the vulnerabilities and their remedies, but it is a good introduction to the concepts of web application security. You can learn more about Clearent’s PCI Certification and Compliance by following the link.

OWASP Vulnerability 10 - Unvalidated Redirects and Forwards

This article was originally published on the Clearent Developer blog.

In a previous post, 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:

https://www.example.com/pagewithredirect.asp?link=someothersite.com

A simple, brute-force approach to preventing this vulnerability is to use a white list for redirects and forwards.  This approach codifies an “approved” list of valid URLs that can be used in an HTTP redirect or forward.  The application would verify any URL against this list.  If an application must use query string parameters to pass URLs for redirection, it is recommended to use a white list for the permitted values in that parameter.  The application should ensure that the value passed in is in the white list before actually issuing the redirect.

A similar approach to a white list is to map the allowed URLs that can be accepted as a parameter.  For instance, the browser may see

https://www.example.com/pagewithredirect.asp?link=desired_site

When the page pagewithredirect.asp parses the link parameter, it would then look up “desired_site” from a mapping and use the URL associated with the “desired_site” key.

Most modern web applications are built on top of an application framework such as MVC in a .NET application or Spring in a Java application.  These frameworks utilize a routing system that dictates how HTTP redirects are issued.  These frameworks do not use user-entered data to change the browser navigation.  They use application-defined paths that are traversed by the routing system.  In this way, applications built on top of these frameworks prevent malicious users from causing an application to route a user to a malicious site.

As we have seen, preventing Unvalidated Redirects and Forwards is fairly straightforward.  In future posts, we will do a deeper dive on the other security vulnerabilities.