Programming for Security
Alosh Bennett
What is computer security?
Protection of information and property from theft and corruption while allowing it to remain
accessible and productive to the intended users.
~wikipedia
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
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
Defending against attacks:
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
Defending against attacks:
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
Defending against attacks:
Always validate the inputs
Reject input larger that you expect
Handle error cases
Put a limit on the load you can accept
Hacking – Escalation of privileges
Find tasks which run with admin privileges
Replace the tasks with your tasks
Disrupt a task running with admin privilege could give a command prompt
with admin privileges
Windows XP run screen saver as admin user
Replace screen saver with a command prompt
Windows will now launch an empty command prompt as admin user
Defending against attacks:
Rule of least privilege – Run the task only with required privilege
Handle error cases without crashing
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
When building applications
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?
cd to upload_directory
for files in dir
if filename does not end with .c or filesize > 100
print("not a valid assignment file")
exit 1
end loop.
for files in dir
upload file to server
end loop.
When building applications
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
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
When building applications
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 anything’ or 1=1 --
select count(*) from users where username = ‘Sheroo’ and password = ‘anything’ or 1=1 –- ’
This sql would work for any username, thereby granting him access to any user account
Exploit – SQL Injection
When building applications
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 <script type="text/javascript">alert('hacked');</script>
<body>
<br>
hello = <script type="text/javascript">alert('hacked');</script>
<br>
</body>
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
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
have registered
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
