Main / Edit version 4 / Edit version 5 / / Users Area

Difference "Secure Programming with CppCMS" ver. 4 versus ver. 5

Content:

## Introduction

Security is one of the major concerns in development of web applications as they are instantly exposed to the world that is full of potential attackers.

Writing web applications today is very similar to walking

over a minefield. If you don't have proper tools and knowledge you are most likely going to loose a "virtual lag".

## State of Mind

There are several golden rules in writing secure web applications:

1. Never trust users input.

2. Think - "How can I attack my application"

3. Learn common vulnerabilities and methods of their prevention so you at least would not do the mistakes others did.

So when it comes to writing web applications always remember that there *is* somebody who would actually try

to something bad to your site and you are lucky if you

will discover this.

What is even more important that at some point, your

_will_ make a mistake and your web site

_will_ be cracked and you'll have to do a hard work

to restore it. So keep backups and even more important

check your [restore procedures](http://www.joelonsoftware.com/items/2009/12/14.html) work.

## SQL Injections

This is one of the most basic problems that

web developer should be familiar with.

Have you ever written code like:

std::string query=

"SELECT 1 from users "

"WHERE username='" + username +"' AND "

" password='" + password "';

mysql_query(conn,query.c_str());

...

What is the problem?

Assume that password value is

' OR ''='

So the query would look like

SELECT 1 from users

WHERE username='user' AND

password='' OR ''=''

Which would always return 1...

So you get authenticated for knowing SQL `:-)` and not

having proper password

If you had ever did it then you should never do

web development till you read this article:

[SQL Injection](http://en.wikipedia.org/wiki/SQL_injection)

How do you prevent SQL injections?

Use prepared statements. [CppDB library](http://art-blog.no-ip.info/sql/cppdb/) provides all tools you need.

Just rewrite the example above"

sql << "SELECT 1 FROM users "

"WHERE username=? AND password=?"

<< username << password;

Now the values of ? would be _properly_ substituted

with correct values with their real equivalent.

The query as value would be physically separated.

## Sessions

HTTP protocol is stateless so in order to keep

a track of the users on our web site we store

an information in the session. For example:

session().set("username",username);

Now we can know who is the user. Now if we have

the `username` in the session we know what he can

do for example.

There are two ways to store the data in the session:

1. Store all the data at the server side saving a unique

session id at the client side in cookie.

2. Store all the data at the client side in a cookie and

we ensure its validity by digitally signing it.

This cookie is very valuable information as if attacker

gets this cookie he can impersonate himself to this

particular user.

### What to store in the session?

It is ok to store some not-so valuable information

like user name user id and may be some properties

then can affect user itself.

However there are several things you should not

keep in session: user permissions and rights.

Remember that each user can have more then one active

session. Consider you store his rights in the session,

now we want to drop his right and we can't as we don't

know which sessions belong to the user.

### Session handling is cookie based

In CppCMS session handing is cookie based and

only cookie based, so trust CppCMS and don't

reinvent your own methods.

There are many popular methods to store session

id that have design flaws. For example, consider

a popular method of keeping session id in the query string:

http://www.mybank.com/?sid=1234564435

Now publish a link `http://attckers_site.com/` on the

`www.mybank.com` web site and you'll get users session id

in the Referrer HTTP header... Now attacker can go

to `www.mybank.com` add `?sid=1234564435` to the URL

and transfer all users money to himself.

So don't reinvent the wheel, use CppCMS session

mechanism that handles this in safely for you.

### Client side storage considerations (Replay attack)

Client side storage is very useful as it allows to

keep all the data at the client side without need

of keeping tack of file system or using DB for

the session storage.

This is especially critical for high performance

applications.

However client side storage has one important

security problem - we have no way to invalidate it

by anything else then timeout.

Consider a situation were we playing a game where

on each level we need to select a one answer from 4.

Now consider user had made a mistake. Now he is not

pleased and he restores his previous cookie and now

goes to the same level again - returns back in time.

There is no way to reset his session to level 1 because

he always can go back in time.

So client side storage in very good thing to use but

you should be very careful with it.

### Session Fixation

This is a kind of attack that is used for impersonating

other users.

Consider example:

1. Attacker goes to a bank side and receives a session id - special cookie.

2. Attacker injects this cookie to the innocent user using

some kind of XSS attack (see below).

3. User logs in into bank, because the had received the

cookie he already has the session id and this session id

receives some additional rights like to do operations

on the bank account.

4. Attacker goes to the bank site using the same cookie

stored in the user's browser and performs any kind

of operations user can do.

How to prevent this?

cppcms::session_interface::reset_session();

By calling this function during the critical operations

like user log-in the session id would be replaced with

a new one:

if(authentication_ok()) {

session().reset_session();

session().set("user_id",id);

}

This simple operation would prevent session fixation attacks.

## Cross Site Scripting (XSS)

## Style Sheets

## Cross Site Request Forgery (CSRF)

## Cryptographic Tools

## Character Set Considerations

## C and C++ Security

### General Notes

### Buffer Overflow

### Integer Overflow

### Dangling pointers

## What happens if we still fail?

## Links

- [Ruby On Rails Security Guide](http://guides.rubyonrails.org/security.html)

- [Open Web Application Security Project](https://www.owasp.org/index.php/Main_Page)

- [XSS Cheat Sheet](http://ha.ckers.org/xss.html)

About

CppCMS is a web development framework for performance demanding applications.

Support This Project

Navigation

Main Page