Authentication and Authorisation

Auditing and Logging

Logging usually means recording certain events that happen within an application. Focus lies on the interests of the developer. Auditing is about recoding specific events usually with specific parameters, sometimes there is a legal obligation to record events.

Note that these events can become of interest for information disclosure if too much information is being logged.

Error handling and Logging should go hand in hand. Correct error handling logs all necessary information to further analyse the incident with brief information provided to the user.

Logs are often the only record that suspicious activity is taking place, therefore logs should be real-time provided to intrusion detection systems to assist monitoring of systems.

Logs can easily fill up storage if not done properly. To control the size and overheads of logging, avoid logging entire database tables or records sets. It is best to simply log a reference to the code rather than logging actual source code chunks

Best Practices

Any information that is intended to be kept confidential should never be logged

Use a separate logging mechanism, like syslog

Logging without acting on the logs is useless, act on the logs

Session Management

Just because someone is authenticated and authorised to access system resources does not mean that security controls can be lax after authenticated session is established, because a session can be hijacked. Session hijacking attacks happen when an attacker impersonates the identity of a valid user and interjects themselves in the middle of an existing session, routing information from the user to the system and from the system to the user through themselves.

In computer science, session hijacking, sometimes also known as cookie hijacking is the exploitation of a valid computer session—sometimes also called a session key—to gain unauthorized access to information or services in a computer system.

Web authentication had an issue in that HTTP is a stateless protocol. Therefore, in order to introduce the concept of a session, it is required to implement session management capabilities that link both the authentication and authorisation modules:

Best Practice

Used to manage authenticated users, no need re-authenticate

You need to make sure your session IDs have sufficient entropy

Session IDs must not be predictable or reusable

Never build your own session management, it will fail

Protect session IDs when in transit (e.g. use SSL!)

Issue a new value for sensitive actions (e.g. funds transfer)

Secure Communication

An architectural decision must be made to determine the appropriate method to protect data when it is being transmitted. The primary benefit of transport layer security is the protection of web application data from unauthorised disclosure and modification when it is being transmitted between clients (web browsers) and web application servers, and between the web application server and back end and other non-browser based enterprise components.

SSL 2 and 3 not secure enforce TLS and force SSL 3 upwards. You can use unit tests to make sure the correct library versions for encryption are being used. Communication between browser and web server should be secure

We have mentioned in previous principles the importance of protecting specific pieces of information whilst they are in transit and we will expand on that now. The requirement to protect data in transit is not a new requirement but it is something that applications often fail to implement.

Encryption is a good thing when it comes to security but it has an obvious downside. Once traffic is encrypted then most scanning tools for malware and known vulnerable APIs are rendered useless. There is a battle at the moment between Tech companies like Apple and Facebook with national security entities like FBI, MI5 and NCA because most messaging apps have end-to-end encryption. These authoritises would like to be able to look at messages that users are exchanging yet the likes of Apple and Facebook depend on enforcing privacy of messages between their users.

This is perhaps the simplest principle to get right, make sure your applications enforces the use of secure transport mechanisms such as SSL, TLS or SSH. You must also make sure that your application enforces specific secure versions of these mechanisms such as SSL version 3 or SSH version 2. Used properly encryption will mitigate man-in-the-middle attacks.

Man-in-the-Middle Attack

Best Practice

Protect data (i.e. Credit Card no, passwords, session IDs) in transit

As with all crypto, don’t create your own

Don’t use broken protection mechanisms (i.e. SSLV2)

Don’t just use SSL/TLS for logon pages, protect the session!

Try and avoid mixing secure and insecure traffic on a page, do everything securely

Secure traffic is not a performance hit anymore

Secure Resource Access

Securing access to your application resources has been touched on in several of the previous principles hence we will be brief here. The issue of authenticating and authorising users along with secure session management have been covered already but these can be undermined by poor design decisions. Every source of information is a resource, from webpages to files and backend services.

Best Practice

Obscurity != security, don’t try to hide sensitive resources

Understand the user flow through an application, secure weak points

Secure Storage

Most applications have a need to store sensitive information, either in a database or in a file system somewhere. The requirement to securely store data such as credit card numbers is obvious but we must also secure data such as passwords and session details whilst they are at rest. You not only need to identify what data needs to be protected but also which mechanisms you will use to provide the protection.

A few areas where mistakes are commonly made include:

failure to encrypt critical data

insecure storage of keys, certificates, and passwords

improper storage of secrets in memory

poor sources of randomness

poor choice of algorithm

attempting to invent a new encryption algorithm

failure to include support for encryption key changes and other required maintenance procedures

The impact of these weaknesses can be devastating to the security of an application. The selection of the protection mechanism should follow the same guidelines as selecting one for secure communications; never create your own and do not use weak mechanisms such as DES, MD4, and SHA-0. We do not want to turn this principle into a cryptography lecture but you should ensure that the following bit sizes are used for Symmetric, Asymmetric and Hash mechanisms

Symmetric – 256 bits or above

Asymmetric – 2048 bits or above

Hashes – 168 bits or above

You should also provide a secure location for any keys you are using; Storing them on application servers generally would not be a secure location

The easiest way to protect against cryptographic flaws is to minimise the use of encryption and only keep information that is absolutely necessary. The final thing to avoid is the hard coding of keys into your code, not in the app, store in the hardware key module.

Best Practice

Protect data (i.e. credit card no, passwords, session ID’s) when stored

As with all crypto, DON’T create your own

Don’t use broken protection mechanisms (.e.g. DES)

Don’t store data in places where you can’t confidently secure it

Strong protection mechanisms, how strong should it be?

Cryptography

The impact of cryptographic vulnerabilities can be extremely serious and disastrous to the business, ranging from disclosure of data that brings with it fines and oversight (regulatory and compliance) to identify theft of customers details, reputational damage, and in some cases complete bankruptcy.

When it comes to cryptographically protecting information, the predominant flaw in software is the lack of encryption of sensitive data.

We have a whole section on cryptography to follow…

Conclusion

Why Principles

11 principles

Best practices