programming for security

8/8/2019 Programming for Security

http://slidepdf.com/reader/full/programming-for-security 1/25

Programming for Security

Alosh Bennett



What is computer security?

Information and property should be

Kept out of reach of unauthorized users

Can only be modified by those who has permission to do so

Accessible to intended users

Security applies to

Information

Computer System

A resource is secure if it is

Confidential

Integral

Available

Protection of information and property from theft and corruption while allowing it to remain accessible and

productive to the intended users.

~wikipedia



Building a secure application

Why do you have to make an application secure?

Loss of confidential and personal data

System becomes unusable

Loss of trust and credibility

Very costly

How to make an application secure?

Make application free of vulnerabilities

What causes vulnerabilities?

Bad design

Coding errors

Lack of subject knowledge Lack of awareness



How does a hacker work?

Find out about the system

What OS is the system running?

What are the input/output?

Probe the system

Interact with the system

Push the buttons

Make the system verbose

Make system talk back Are there log files?

Make the system unstable

Give wrong inputs

Overload the system

Get access to the system/ gain more privileges Try guest user

Is there any task running with elevated privileges?



Hacking ± Know the system

Scan for open ports and interfaces

URLs and ports tell you about the services running

There could be known exploits for the OS and server versions

Packet Sniffing

Using packet sniffing you could listen to the data sent by the system

There could be confidential information like passwords

Look for password files

Unix stores passwords in the file /etc/shadow

Defending against attacks:

Do not run any unwanted service Store password files with correct permissions

Do not store passwords in plain text



Hacking ± Probe the system

Try different URLs

If there is http://mysite.com/php/login.php

http://mysite.com/php/ could do a directory listing

Editors mostly leave backup files login.php~

Look for test files test.php

Login and test files could have database username, password and

validation logic hard-coded

Try for default accounts/ master passwords

Look for plain text files


Keep application clean by removing backup files and test files

Never hard-code username/password into the code

Do not leave sensitive plain text files in the server directory

Disable/change default accounts

Never keep a master password.



Hacking ± Make system talk

Make an application verbose by running in debug mode

In most of the applications

--debug runs the application in debug mode

-v or -±verbose makes it verbose

Get hold of log files

Log files sometimes contain sensitive data

They tell you more about the internal working of the system


Do not put internal details into log files

Do not put confidential information into log files

Keep log files out of reach of normal users



Hacking ± Unstable system

Give incorrect input

Give string where number is expected

If this is not handled, the program would crash Give negative numbers for quantity

Ordering an item in negative will bring down the total bill

Give past dates/future dates

Give huge requests

Enter 3 to 4 lines for the name field This could cause buffer overflow!

Give huge numbers

In C, int 32768 is lesser than 32767

Give lot of requests

Swamping an application with request could crash it

Force the application to error.

If error conditions are not handled they are displayed to the user

Error logs and core dumps are gold mines of information



Hacking ± Unstable system


Always validate the inputs

Reject input larger that you expect

Handle error cases

Put a limit on the load you can accept



Common vulnerabilities

Packet Sniffing

Man in the Middle Race Condition

Buffer Overflow

SQL Injection

Cross Site Scripting

Hidden Field Manipulation

Cookie Poisoning



Exploit ± Packet Sniffing

Wireless networks broadcast all the packets to everyone

Each machine accepts packets addressed to it and discards the rest

Using network monitoring tools it is possible to accept all packages

Using these tools, you can easily reconstruct the entire html content

Not only the page being displayed, but data sent to a site can be seen

If your application sends username/password and other sensitive information it

could be seen

When building applications

All sensitive information should be encrypted

Use standard encryption algorithms

µterces¶ and µvhfuhw¶ are not safe encryptions of µsecret¶

Secure the network to restrict outsider access

Avoid broadcasting if possible



Exploit ± Man in the Middle

Hacker sees user trying to contact the server

Hacker intercepts the message and connect to client pretending to be the server

Hacker also connects to the server pretending to be the user This way he can control and manipulate the conversation

In desktop scenario,

Consider a trusted program /bin/ssh

Hacker installs /opt/temp/ssh

Hacker changes environment variable $path to /opt/temp Invoking µssh¶ would now invoke the malicious code along with the password you give


Establish identity of the person or code you are talking to

Digital certificates and signatures help establish identity in web applications

Use complete path instead of relative path when dealing with commands/files



Exploit ± Race condition

This exploit uses the delay in a program between verifying input and executing.

You start by passing valid input, but change it in between verification and execution

Consider a script to upload assignments to college server Script allows only .c files and files lesser than 100 KB in size

You want to bypass the check to upload mp3s and movies

Consider following code, is it safe?


Atomic operations are operations which should be done as a single unit

Verification and execution should be done as a single unit

In your application, keep a note of all externals that could change during running

Race conditions are more common in multi threaded application

cd to upload_directory

for files in dir

if filename does not end with .c or filesize > 100print("not a valid assignment file")

exit 1

end loop.

for files in dir

upload file to server

end loop.



Exploit ± Buffer overflow

Accounts for more than 80% of all vulnerabilities

Caused by writing more data into a variable than it can hold

Consider two variables with values UserName = ³SHEROO´

Type = ³GUEST´

UserName Type

S H E R O O G U E S T

If you store ³SHEROOLIONADMIN´ in the variable UserName, Type gets overwritten

UserName Type

S H E R O O L I O N A D M I N

Using buffer overflows you can

Overwrite and modify protected variables

Overwrite call stack return address to a particular address and execute target code

Cause the program to crash and core dump, revealing sensitive information



Exploit ± Buffer overflow


Always check the bound conditions and size of array and other data storages

Use fgets(username, 10) instead of gets(name) Use free and overflow safe APIs for strings and arrays instead of standard library

³Better String Library´ and vstr are such safe libraries

Use languages which does the memory and pointer management

Languages like java, python allocates and de-allocates memory for you

They have bound checks built into the application

Supports variable length lists instead of arrays Do not give pointers to any memory location



Exploit ± SQL Injection

Happens when user input is used to prepare SQL statements

Consider following code which prepares the SQL

String userName;

String password;

String sql = ³select count(*) from users where username = µ³+username

+´¶ and password = µ³+password+´¶ ³;

If the userName is ³Sheroo´ and password is ³topsecret´, sql becomes

select count(*) from users where username = µSheroo¶ and password = µtopsecret¶

If a hacker enters a password as

select count(*) from users where username = µSheroo¶ and password = µanything¶ or 1=1 ±- ¶

anything¶ or 1=1 --

This sql would work for any username, thereby granting him access to any user account



Exploit ± SQL Injection


Always check input for unwanted characters

Never build SQL dynamically Use binding or other safe mechanism for creating sql

String userName;

String password;

String sql = ³select count(*) from users where username = :1 and password = :2 ´;

sql.bind(1, userName);

Sql.bind(2, password);



Exploit ± Cross Site Scripting

XSS tries to execute custom javascript on any website by passing javascript snippets as data

The website displays this data by adding it into html without verification

Consider the following jsp code

<body>

<br>

<%

String name = request.getParameter("name");

out.println("hello "+name);

%>

<br>

</body>

If you enter µSheroo¶ as the name, the html generated will be

<body>

<br>

hello Sheroo

<br>

</body>



Exploit ± Cross Site Scripting

If you enter the name as

Using XSS you could,

Extract the information in the page

Modify the contents

Steal the cookies

The javascript could be persisted by putting them as comments

When building application, Do not trust user input

Check the input for unwanted characters

Remove any script tag

<body>

<br>

hello = <script type="text/javascript">alert('hacked');</script>

<br>

</body>

<script type="text/javascript">alert('hacked');</script>



Exploit ± Hidden field tampering

Any information displayed in an html form could be edited, including hidden fields and

dropdowns

Consider a college site which allows you to download course material for courses you haveregistered

When you log in, there would be a dropdown to select the course.

It is possible to edit and add more options to the dropdown from the browser

If hidden fields are used to store critical information like user_id, they could be edited as well

When building application,

Do not send critical information like user_id to browser. Store them in session

In case user selects a value from a list, validate the selection at the server once more

In case where you have to send a value to browser and you don¶t want it to be tampered,

append the value with hash functions



Exploit ± Cookie Poisoning

Cookies contain user login details

Cookies are stored as text files on the user¶s machine

When you open a site, cookies belonging to that site is sent automatically by the browser Consider a cookie user=sheroo:session_ticket=HJGAS12827KH6

It tells the user is sheroo

It contains the session_ticket.

If the ticket is a valid one, user is automatically logged in

It is possible to modify this cookie to user=admin:session_ticket=HJGAS12827KH6

This could log the user automatically as admin

When building application,

The username should not be stored in a way it can be tampered.

It should be stored with a valid hash appended to it.



Tips to secure your code

Design application with security in mind

Security cannot be added as an additional layer

Eg. unix operating system Write error free code

Buffer overflows are result of programming errors

Use absolute path over relative path

Handle errors properly

Maintain clean code

Good access control mechanism

Store and transmit username/password in a secure manner

Different users have different privileges

Least Privilege Rule

Run your application with least privileges

Secure default accounts

Defense in depth Cryptography and Sensitive information

Passwords should be stored encrypted and without access to others

Use standard cryptography methods like Public Key Cryptography

Do not log sensitive data



Tips to secure your code

Sanitize input data

Do not trust user input

Clean data avoids SQL injection, Buffer overflow, XSS Secure running environment

Do not let user specify log locations

Do not rely on unsafe environment paths

Remove test and backup files

Run untrusted code on virtual machines



References

Secure Coding: The State of the Practice by Mark G. Graff

http://en.wikipedia.org/ http://www.securecoding.org/

http://java.sun.com/security/seccodeguide.html

Slides available at

http://www.aloshbennett.in/weblog/

Thank You

programming for security

Documents