Miscellaneous Security

Reading time: 2 – 3 minutes

Photo: jaeming

Being security aware and security conscious often boils down to understanding three key concepts that are common to risk management

These security concepts have been around since the inception of information security. Although, these are high-level generalizations, they are important for everyone to know about.

This article is focused on understanding how each of these apply to information systems.

Confidentiality

Confidentiality loss happens when information can be viewed (read) by individuals who shouldn’t access it.

Loss of confidentiality can happen physically or electronically.

Electronic confidentiality loss can happen when the clients and servers aren’t encrypting their communications. This allows malicious entities to view private communications.

Physical confidential loss can happen through social engineering or through theft. This typically means having laptops stolen.

Integrity

Integrity loss happens when information is modified without the modification being authorized. This doesn’t mean that an unauthorized party has to cause the integrity loss to happen. The integrity loss due to an authorized party doing something they shouldn’t. An example would be a system administrator deleting an account record they weren’t authorized to delete.

Integrity Loss can happen either accidentally or through malicious intent. Malicious integrity loss can happen when a user purposely adds, deletes, or modifies database records. This can occur either through an authorized party (someone who has the access to actually modify the record) or by an unauthorized party when the user has access that they shouldn’t have.

Accidental integrity loss happens when a system modifies or deletes records that it shouldn’t. This can happen when a virus infects a system or when a user does something that he didn’t intend to do. This is often why systems will verify that you want a file deleted, before it actually does so.

Availability

Availability is the simple idea that when a user or system attempts to access something, it is available to be accessed. This is extremely important for mission critical systems. Availability for these systems are so critical that most companies have business continuity plans (BCP’s) in order for there systems to have redundancy.

Just like confidentiality and integrity loss, availability loss can happen by accident, a car crashing into a fiber pole disabling access to a system, or through malicious intent, such as a Denial-of-Service attack.

Reading time: 2 – 3 minutes

Photo: Joe Penniston

This is the fifth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Cross-Site Request Forgery (CSRF)

Cross-Site request forgery is a client-side vulnerability that allows an attacker to make requests on the user’s behalf. Although, most CSRF exploits require a user to be authenticated to the susceptible site to be successful, this is not always the case.

An Example of Cross-Site Request Forgery

A user (victim) opens their browser and logs on to their online banking application located at http://bank.com

After checking their balance they browse away from the site (without logging off) and start reading web pages about olives from Madagascar. One of these olive sites is owned by an attacker. The attacker’s website has the following img src tag:

<img src="http://bank.com/transfer.asp?to_acct=445544&amount=1000">

When the victim’s browser loads the malicious page that contains this img src tag, the victims browser makes the transfer request (/transfer.asp?to_acct=445544&amount=1000) to bank.com using the authenticated cookie from the earlier session. Upon making this request, the bank then transfers $1,000 from the victim’s account to account 445544. The attacker has now successfully executed a cross-site request forgery attack against a user of bank.com

How Do You Prevent Cross-Site Request Forgery

Any sensitive request that is generated by the user should force the user to “re-authenticate.” A simple example is that of change password functionality. You always want to verify the user knows the old password before changing their password, even if they are currently authenticated.

If you determine that “re-authentication” may be an inconvenience for the user or if all of your requests are considered sensitive then the application developers should include a random token that is unique to the user session. This token should not be present in the cookie, but rather as a hidden field in the HTML and then appended to the URL during any form submission.

When the attacker attempts to trick the users browser into making a request, the web application will look for this random token. The random token will not exist for the request, and the request will be denied. This prevents the CSRF attack from being successful.

Note: Having SSL does not protect your application from CSRF vulnerabilities.

Reading time: 1 – 2 minutes

Photo: XKCD

SQL Injection is an injection flaw where a web application allows a user to send un-sanitized input into a SQL query.

The textbook example is that a web application has a username field that inserts the user’s input into the following SQL query:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

The user then types a' or '1'='1 into the username field. This creates the following SQL statement:

SELECT * FROM users WHERE name = 'a' or '1'='1'

If the statement variable is used for the authentication procedure then the evaluation of the SQL statement will always be true.

An attacker can cause damage if they appended something like, '; DROP TABLE users;--

This would produce the following SQL statement:

statement = "SELECT * FROM users WHERE name = ''; DROP TABLE users;--';

Which would result in the users table being deleted from the Database.