Archives

I’ve been doing a good deal of PDF generation in Rails, and had to go through the process of comparing all the available techniques and frameworks in order to find the right solution for my needs.

Its great that there are so many tools out there, but it can be a daunting task to figure out which is best, which will scale, which will continue to grow and improve, and to evaluate the true ‘cost’ of free vs. commercial.

With all this info finally digested and sorted out,  I was surprised when I got a client request to be able to add a banner to an existing pdf, and from what I can  recall, none of the libraries I know about seem able to do this.  Right now, I’m in the middle of googling the hell out of it, but haven’t found my silver-bullet answer yet.  (maybe I should ask jeeves?)

I’ve done various searches and have come across a few categories of PDF tools:

1. Wrappers to existing pdf generation tools like fpdf, and iText
2. PDF Template tools where you build a pdf skeleton file, and bind values to it programmatically
3. Pure Ruby PDF Generation tools
4. PDF Readers and inspection tools

I did find a discussion about how this could work on Google Groups between Greg Brown creator of Prawn and Ruport, and James Healey developer of PDF::Reader, but that discussion basically ended with, “Yeah, that would be cool!”.

At this point I’m looking into the Origami library which is actually designed for pdf ‘security’ and testing, and isn’t explicitly designed for editing pdfs in this way, but at the moment its the leading candidate in my list.

Have I missed something? Is there an obvious way to do this in ruby/rails that I’m completely overlooking? (I haven’t looked very deeply at tools that shell out to the bigger libraries, but I wouldn’t rule them out)

The initial requirement was to be able to add a banner/header to an existing PDF, but I can see the complexities of determining how to shift the existing content down without screwing up all the formatting, so I think even being able to insert a coverpage might be a suffcient implementation for now. (Maybe I should be searching for pdf ‘merging’ instead of editing)

I’ll update you with my final solution in an upcoming blog post, and I’ll be covering all of the info I’ve learned on PDF Generation tools for Ruby and Rails  at this year’s WindyCityRails Conference on September 12th. Drop by http://windycityrails.org to register. (early registration ends Aug 1st)

In Yesterday’s post I said I’d put together a quick list of things to think about around web application security. This is by no means an exhaustive list, but its a set of categories and things I start to look at when doing a security assessment on an app.

Web Application Security Checklist
Account management

• Password management (validation, expiration, previous passwords, etc)
• Account lockout (number of tries, IP auditing, etc)
• Role management

Data management

• Don’t Leak sensitive user info (SSNs, account numbers, other identity info) in URLs, cookies, sessions, logs, or printable pages.
• User Auditing (who changed what, and when)

Browser hacks

• Cross Site Scripting (XSS)
• Cross Site Request Forgery (XSRF)

Encrypted transport (make sure Ajax calls are secure)
Encrypted storage (credit cards, ssns, etc)
Server configuration (firewalls, web/app server, db)

I actually have a longer list, but its not formatted/organized very well,  so this is my first cut at sharing it with others.

What other areas do you look at when doing security checks for your web apps?

What tools do you use?

Photo Credit:
Amagill under Creative Commons Attribution

Security is hard

Security is often an after thought, slated towards the end of a project, or after some big issue has been discovered, but the nature of security functionality, rules, roles, auditing, etc make it hard to layer in to an existing codebase effectively.

Oh, and if the code base isn’t sufficiently tested, you’re in for a world of hurt.

If you are a developer that was just asked to ‘do a quick security check and plug any holes’, you are now in the difficult position of managing the expectation that a two-week security review means “we’re covered”. Be realistic about what you can accomplish, setting out some short-term and long-term goals.

Do More With Less. Start with a research ‘Spike’

Instead of pushing for more time to be able to ‘cover it all’ (even though you have no idea what ‘it all’ is yet), it might be better to start with a shorter analysis phase, where you detail your findings, identify any trends, and include recommendations for process change. I’ve found that even the most demanding manager is appreciative and understanding when you ask for a small amount of time in order to produce a better estimate, than to just immediately demand more time without any evidence as to why.

Plan for success

With your analysis and recommendations in hand,

Security is unlike other aspects of software in that it follows a steep value curve: either your system is secure, or it is not. Either it provides its full level of value, or it provides none at all. There is often a tendency to address security up front (even when other aspects of the system are built iteratively). What others sometimes fail to see is how this generates unneeded cost and complexity as the project matures.

You knew it had to happen. Malware for Firefox. It happens all the time with IE (so much so that my 17-year-old niece needs a fresh install of Windows every 3 months), but Firefox has been a little less prone — though not imune — to malware. See the BitDefender blog post and the Infoworld article which has a bit more detail.

Now Firefox 3 does contain Malware protection, but apparently this plugin is delivered via other system compromises to the filesystem, and apparently Firefox doesn’t question already installed plugins.

BTW, the malware registers itself as GreaseMonkey. If you care to, you can follow the Slashdot food fight on this topic.

More as I find out more…

“Only administrators can add users– no exceptions! …except Bob in accounting, but that’s because he’s covering for Sally. But only until February. And this sort of arrangement might happen again. But most of the time, it won’t. I mean.. ninety-nine point nine percent of the time. But there might be exceptions… “.

Sound like a requirement you’ve heard before? How did you handle it?

In an earlier post, I stated that all security models are idiosyncratic, and that the way you go about designing for security must reflect the nuances and -isms of your organization. You might mistake the form used to express the model (HR records, existing databases, or some XML schema) as your security model, but you risk an uphill battle getting your organization (and I mean the people here, not boxes and circles on an org chart) to accept the result.

All of this has less to do with how we design software and everything to do with the way people organize into groups..

Security is an area of concern where value and cost are often difficult to estimate.  While big mistakes made early on in many areas of an application may prove difficult to correct, this is especially true for security, since its specifications often model a direct reflection of an organizational structure.

And all too often, dysfunctional organizations create dysfunctional security requirements.

It is common knowledge then that a failure to account for security from the start can prove much more costly in the end.  However, over-engineering security needs can require so much effort that your team may not have enough time left over to actually build the very features you are trying to secure.

I find the following two points very useful to keep in mind when participating in discussions concerning security regardless of the application, but especially when working under the assumption that a new application needs the same kind of security model as the old application:

• All security models are idiosyncratic
• Never underestimate the cost of being flexible

These two items work as polar opposites of each other:  a flexible system can accommodate many types of organizations, but not without the added cost of training, installation, documentation or maintenance. On the other hand, a static model is cheap to build, but rarely captures the nuances of an organization’s structure, particularly as business needs evolve over time.

In the announcement that the OpenAjax Alliance had released OpenAjax Hub 1.0, and would start to work toward 1.1, there was one thing that caught my interest: the news that 1.1 would support secure mashups. Given that proxies and JSONP are both pretty open to abuse by unscrupulous service providers, this was certainly welcome news? So, what exactly does this secure mashup support look like?

The nascent SVN repository at Sourceforge wasn’t much help — mostly just a placeholder for future work. A little digging reveals that the OpenAjax technology will be based on a technique known as ‘SMash’, developed at IBM for performing secure mashups. I was able to locate a copy of a research paper on SMash (not sure if this is meant to be public, so grab a copy).

I’m still absorbing the densely packed information from "Ajax Security," the first-rate book by Billy Hoffman and Bryan Sullivan that I recently recommended in these pages. Here, in no particular order, are three of the most surprising lessons imparted by Messrs. Sullivan and Hoffman:

Web aggregators and SSL

This is probably a great big "duh" to some developers, but web aggregators such as iGoogle and NetVibes often compromise the security of otherwise SSL-encrypted web applications when funneling content from them to your personalized homepage:

Now, consider what happens when you use a Gmail widget on an aggregate site like NetVibes. Sharp-eyed readers will notice the URL for NetVibes … is http://www.netvibes.com. This is not an encrypted connection! NetVibes sends user data in the clear from the aggregate to the user…. NetVibes makes an SSL connection to Gmail, and then NetVibes degrades the level of security by transmitting the data over an unencrypted connection. Our attacker … can steal the data much more easily now. NetVibes is not providing the same level of security that a user would receive if he accessed Gmail directly. This situation is not unique to NetVibes and Gmail…. At the time of publication, every major aggregate Web site the authors examined downgraded security on data from secure sources. [emphasis theirs]

Reviewers overuse the phrase "required reading," but no other description fits the new book "Ajax Security" (2007, Addison Wesley, 470p). This exhaustive tome from Billy Hoffman and Bryan Sullivan places the specific security concerns of the Ajax programming model in historical perspective. It demonstrates not only new security threats that are unique to Ajax, but established threats that have gained new traction in the Web 2.0 era. It then details both the specific technical solutions and – more importantly – the mindset that are necessary to combat such threats.

Because so many developers have historically overlooked the importance of security, the authors approach their topic for what it is: a remedial subject. They take pains to explain the basic mechanisms by which hackers have exploited insecure web applications over the last decade: cross-site request forgeries, denial of service attacks, cross-site scripting and SQL injection. Then they explain how those mechanisms have changed thanks to the rise of xmlHttpRequest, public APIs, mash-ups and aggregators. If you’ve ever read a Douglas Crockford rant about the "brokenness" of the web security model and wondered why the guy was such an alarmist, Hoffman and Sullivan are only too happy to provide you with a much-needed wake-up call.