Category Archives: Security

A Simple Form Nonce Security Routine Written In PHP

One Web security task that slips through the cracks, even for experienced developers, is ensuring your forms originate on your server, through the use of a nonce, or a one-time, unique identifier for your form.

Why is this important?

  • A favorite attack vector is to duplicate forms on a remote server, and attempt cross-site scripting (XSS) attacks that way. It’s far more convenient to me to write a curl routine that varies up the junk inputs I’m trying to run on my own server, than to run a bot that fills out the target form on its own host.
  • Ensuring your form is submitted only once is most easily managed if you generate a unique identifier, created every time your form is created, and storing that identifier in some persistent data store; namely, a database, XML file or the like.
  • A unique identifier for your form gives confidence your form contains what you expect. We can’t be absolutely sure that a properly formed nonce means your form is 100 percent pristine — we still need to check all inputs are present and contain what we expect — but we can usually begin our security checks by seeing if the nonce is present and well-formed, before doing things that constitute heavy lifting, such as sanitizing other inputs, doing calculations on them and rendering up a response or additional steps.

There are a lot of ways to create a nonce, and how best to proceed depends on what goal you have.

Sometimes, you just need to ensure the form originated on your site; it doesn’t need to be one-time use. Other times, you need to be absolutely certain the form is only submitted once. And occasionally, you need to time-limit when a form can be submitted.

I’ll start by addressing the middle requirement first: A one-time-use nonce, which isn’t time-limited (that is, the nonce can be used anytime, but once used, can’t be recycled). In upcoming blog posts, I’ll address the other two methods.

Continue reading

Apologies: A Server Crash Has Eaten My Media

I’d like to apologize to readers of this blog for a server crash that ate the contents of my wp-content directory recently.

Unfortunately, a lack of vigilance means I didn’t have a local backup of that directory, and my host doesn’t have a backup, either. So most of the images and code downloads are missing.

I plan to fix that as time allows, but time is at a premium. So please bear with me as I do my best to recover. Thanks.

Microsoft’s Advice On Avoiding SQL Injection Attacks

Not to kiss my own ass, but Microsoft’s official advice on avoiding SQL injection attacks sounds awfully familiar to readers of this blog:

Sanitize (validate) all inputs: “This helps to ensure that the input is free from characters that cause SQL injection attacks.” It also allows you to fix the form and data type of the user input, which pretty much renders basic script kiddie attacks useless.

Parameters, not strings, as query variables: “Creating dynamic queries using string concatenation potentially allows an attacker to execute an arbitrary query through the application.”

In other words, it’s harder to break this:

@person VARCHAR(20); SELECT * FROM table WHERE person = @person;

than it is to break this:

SELECT * FROM table WHERE person = 'some user string';

Stored procedures, not free-form queries:Stored procedures by themselves do not remove SQL injection vulnerabilities. They only raise the bar on the attacker by hiding much of the underlying database schema.” That is, the attacker can’t easily find out what columns are in a table, or what type of data is in those columns, if you use a stored procedure.

Minimal permissions: “In general, database applications should be using a low-privileged account that has the minimum permissions required to execute the statements submitted to SQL Server.” As in, create a user in your SQL database whose only permission set is to execute your Web-based stored procedures, and connect to the database server as that user.

Those are the basics. And if you don’t understand how to do them, I’ll be putting together a blog series on how to convert your old string-queried Web applications into one secured with stored procedures and proper permissions.

Continue reading

The Basics Of Avoiding MySQL Injection Attacks In ASP.NET Web Forms

Received in my email today:

Hi

say your blog and thought you might help.

strsql = “SELECT StaffID, DesignationID, StaffName, Password, ShopID from staffT where StaffName =” & UserName.Text & ” AND Password =” & Password.Text & “”

from the string, the username.text and password.text are form controls. what is happening is there are passing null values regardless of what you input in the text boxes resulting in a system error.

“System Error Object reference not set to an instance of an object”

Am using Mysql as the database.

I’m always glad to answer such questions, especially when the questioner is flirting with disaster, as much as this questioner is.

A trained eye can immediately spot the problem with the SQL statement above, aside from the problem of NULL values tossing errors. Namely, it’s wide-open to SQL injection. (And an even keener eye will note that the values for user name and password aren’t delimited with single-quotes.)

So here’s my reply email to the questioner:
Continue reading

Working With authorize.net Server Integration Method (SIM) Payment Gateway, Part 2: Proper Form Design

The most important step in using the authorize.net Server Integration Method (SIM) payment gateway is properly designing your ordering system / shopping cart, well before you ever request payment.

Let me repeat that: If you want a secure, sensible and error-free checkout experience, you need to design a storefront that makes those things possible. Just as it is with building a house, if the foundation is crap, it won’t stand up to a storm.

I promised in a recent post to show how to properly send transaction requests to SIM. So, here’s the first step: An overview of best practices, and a sample order form that follows them.

Let me offer this, right up front: If your Web sales are casual — say, you want to let people buy annual banquet tickets online, or you sell a couple coffee mugs / T-shirts each week — you should seriously consider using a third-party turnkey solution.

The legal, practical and technical requirements of running your own ecommerce solution generally aren’t worth the hassle if you’re not doing a significant volume of sales.

I like EventBrite for handling ticket sales and CafePress for selling merchandise. There are other storefront options out there, but those are ones I have used and found reliable.

That said, there are circumstances where low-volume sellers still need custom ecommerce solutions. So, with that in mind, let’s cover the basics of making a secure, simple ordering system.
Continue reading