ABCpdf is a component presenting an API, much like .NET itself.

Like .NET there are no restrictions on what you can do with the API. If you call File.Delete it will delete a file. That is what the API does.

It is not difficult to make your use of the APIs secure, but you have to actively do it. You need to be making design decisions here.

Each system is different and each system has different needs, however the following are the base principles by which you should operate when securing a system using ABCpdf.

 

Fundamentals

You are in control. You call into ABCpdf. You decide what APIs to use. You decide which parts you deploy. You decide the environment in which it operates. You are in control here and the majority of choices are going to be made by you - not by ABCpdf.

Defense in depth is key. One impenetrable barrier is not enough. You want a series of barriers. If one is breached the others will hold. Layers are what keep you safe.

ABCpdf contains architectural structures which provide defense in depth. Most are internal and are not visible from outside. Some - such as our FireShield technology - are visible and documented.

Most of the defensive layers will come from you because there is a limited amount we can restrict without impacting your ability to use the software.

Evaluate security before you start to write code. Then review your evaluation as your code and architecture develops.

 

Do not trust your users

Attacks can only occur if attackers can provide input to a system. The obvious route in, is via a standard method supplied to your users.

Once this route is compromised an attacker can experiment with various inputs to see how they can manipulate your systems.

Stack overflow exploits, SQL injection and cross site scripting are just some of the many exploits which are based on insufficient input vetting of user input.

You need to be suspicious of the data that is provided to you. Vet it first and make sure it is good before passing it to ABCpdf.

If you store data, consider encrypting it so that a breach will not result in data loss. If encryption is too complex or dangerous, even just a level of obfuscation will add a significant barrier.

ABCpdf will do its own vetting too, but you know much better than it, what it is that you consider to be acceptable.

Vetting Inputs. How should input data be validated or vetted?

Every application is different and every situation needs evaluation but there are some obvious factors which one should bear in mind. At minimum you need to ensure that your inputs and outputs are not excessively large or numerous.

ABCpdf will do its best to accommodate your requests, so if you ask it to do something excessive it will do its best to do so. At that point it becomes a matter related to the OS as to whether it is allowed the resources to do this or not. Better to decide these things yourself rather than leave them up to chance.

For example, if you allow your users to upload TIFF images, consider if it would be reasonable for them to upload a 1TB image. If you allow users to render a PDF, consider if it would be reasonable to allow them to select 72,000 dpi as the target resolution (producing a 500 Gigapixel output). If they are allowed to provide a description for an item in an invoice, should they be allowed to provide the text of Moby Dick?

 

Do not trust your code

ABCpdf is designed to run from a reduced permission environment.

Take advantage of this. Ensure that your code runs in a process as a low privilege user with access only to the resources that it needs.

Where ABCpdf offers further layers of protection, take advantage of them. Use technologies like FireShield to further restrict access and add layers of protection.

ABCpdf is modular so if you do not need a particular module then consider eliminating it. You deploy ABCpdf and you can decide which pieces should be deployed.

Read the documentation for the functions you use and ensure you take note of any security relevant details. If security is mentioned in the documentation it is for good reason.

 

Do not trust yourself

Many of us have blind spots to our failings and there is no more obvious place for this than when we write code.

Users find bugs that developers had never dreamed of. Developers have a rather myopic view of what might happen and how things will work.

The reality is that the code you write will be flawed and you are not the best person to judge the ways in which it is flawed.

You need to submit your code for review by a third party. A third party can be someone else in your team, or for especially sensitive situations you might consider employing a penetration tester.

You should do team-based threat assessments based on the architecture of your systems. Consider the access points and think about how these might expose attackable surfaces.

Automate as much as possible to reduce the possibility that human error may creep in. A complex manual deployment is bound to go wrong sooner or later. Automate to eliminate.

 

Do not trust your machine

You need perimeter security on your host machine. Most obviously this comes from a firewall and anti-virus software.

Do also consider if other technologies might be appropriate, perhaps at the network level.

 

Simple and Secure

Try and keep things simple. It is much easier to secure a system with one access point than it is a system with ten.

The simpler your systems, the simpler it will be to:

  • see if they are designed well and correctly
  • assess any threats they may be vulnerable to
  • know if something goes wrong