Upload
aloshbennett
View
229
Download
0
Embed Size (px)
Citation preview
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 1/25
Programming for Security
Alosh Bennett
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 2/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 3/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 4/25
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?
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 5/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 6/25
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.
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 7/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 8/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 9/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 10/25
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 11/25
Common vulnerabilities
Packet Sniffing
Man in the Middle Race Condition
Buffer Overflow
SQL Injection
Cross Site Scripting
Hidden Field Manipulation
Cookie Poisoning
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 12/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 13/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 14/25
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?
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
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.
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 15/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 16/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 17/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 18/25
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);
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 19/25
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>
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 20/25
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>
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 21/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 22/25
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.
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 23/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 24/25
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
8/8/2019 Programming for Security
http://slidepdf.com/reader/full/programming-for-security 25/25
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