Secure programming - PowerPoint PPT Presentation

an anti hacking guide n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Secure programming PowerPoint Presentation
Download Presentation
Secure programming

play fullscreen
1 / 26
Secure programming
119 Views
Download Presentation
sybil
Download Presentation

Secure programming

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. An anti-hacking guide Secure programming

  2. Hackers are kindred of expert programmers who believe in freedom and spirit of mutual help. They are not malicious. They may be tied to the common belief described aptly by the modern Zen poem stating: To follow the path:look to the master, follow the master, walk with the master, see through the master, become the master. Who is a hacker?

  3. The malicious individuals who break into programs and systems in order to do damage or to steal something are referred to as crackers or attackers. Most attackers are not highly skilled, but take advantage of published exploit code and known techniques to do their damage. Most attackers are not as highly skilled as hackers are, they take advantage of published exploits. Such people who use published code to attack software and computer systems are called script kiddies. Who is an attacker/cracker?

  4. The new Boeing 787 Dreamliner aircraft provides on board internet access to its passengers but concerns were raised about the fact that the flight’s controls were connected to the same network serving internet access to the passengers! What could it mean? What if an Iraqi or Afghan hacker breaks open the networks at Pentagon’s missile stations? Or talking about something that’s close to our chores, what if we leave loopholes in the SPFS codebase which may be exploited to crack the Core Billing Manager? What would it mean to the company that deploys the CBM application? Why should I bother about an attacker?

  5. There are numerous ways an attacker may break applications apart. We’ll take two specifically notorious and very widely used techniques of exploiting software, namely: • SQL Injection • Buffer Overflows What can an attacker do to your code?

  6. SQL INJECTION

  7. SQL injection is a technique that exploits a security vulnerability occurring in the database layer of an application. When an end user is asked for his/her credentials an attacker may inject malicious queries into the database if user input is not strongly typed. Sql injection: What is it?

  8. SQL injection: what is it?

  9. How would the code for checking the username in the login prompt look like? statement := "SELECT * FROM users WHERE name = '" + userName + "';“ Do you see anything wrong with this SQL code? Is it vulnerable? SQL injection: what is it?

  10. NO? • What if an attacker entered the following username? a' or 't'='t • In the original query the completed entry would look something like, SELECT * FROM users WHERE name = 'a' OR 't'='t'; • Do you think this username will ever be wrong? SQL injection: what is it?

  11. And what if a certain noble human being entered the following username? ‘ OR 1=1;DROP TABLE users;-- • The original query will now look like: SELECT * FROM users WHERE name = ‘‘ OR 1=1;DROP TABLE users;-- • As you may see this query will delete the users table completely and comment out any further queries in the statement. SQL injection: what is it?

  12. On November 01, 2005, A high school student used SQL injection to break into the site of a Taiwanese information security magazine and stole customer's information. On January 13, 2006, Russian hackers broke into a Rhode Island government web site and allegedly stole credit card data from individuals who have done business online with state agencies. On June 29, 2007, A hacker defaced Microsoft U.K. Web Page using SQL injection. SQL Injection: Is it really dangerous?

  13. Input Validation is GOSPEL: • Always perform strict type checking of all data input by users. • Don’t ever trust the user. They’re not always noble and trustworthy. • Limit the length of input. • Never use of any of the default database accounts. SQL Injection: The Measures!

  14. BUFFER/Stack OVERFLOW

  15. void foo(char *bar) { char c[12]; strcpy(c,bar); } int main(intargc,char *argv[]) { foo(argv[1]); return 0; } Buffer overflows: what are they?

  16. void foo(char *bar) { char c[12]; strcpy(c,bar); /* No bounds checking!! */ } int main(intargc,char *argv[]) { foo(argv[1]); return 0; } Buffer overflows: what are they?

  17. Before data is copied. BUFFER OVERFLOW: Stack view of the code

  18. When legitimate data is copied, INPUT: "hello" BUFFER OVERFLOW: Stack view of The code

  19. When you’re hacked! INPUT: "AAAAAAAAAAAAAAAAAAAA\x08\x35\xC0\x80" BUFFER OVERFLOW: Stack view of The code

  20. As seen above, an attacker may send junk input to your program and change the return address of functions to anywhere in memory he likes to. That memory location could very well contain attacker implanted code! And imagine, what would happen if the program above was running with super user privileges! One could also modify data contained in variables using buffer overflow! BUFFER OVERFLOW: The trick!

  21. Functions like strcpy(), gets(), strcat(), sprintf() etc. don’t perform a bounds check on the destination buffer. This allows an attacker to copy unsolicited data into the buffer! C and C++ are two languages that don’t perform any bounds checking on the input and are hence vulnerable if one is not careful while writing code. Buffer overflow: The cause

  22. Always use the safe alternatives to strcpy(), strcat(), gets(), sprintf() etc. like strncpy(), strncat(), fgets(), snprintf()! Always fail safely, which means perform error checking and exception handling at every possible place in the code. Remember, don’t trust the user! Grant minimum required privileges to your programs. Buffer overflow: Is there a way out!

  23. Use static code analyzers before you deploy your code! Use Stack Canaries! Use safe libraries! Use Stack Smashing! BUFFER OVERFLOW: Commercially solutions!

  24. NO CODE IS BUG FREE, BUT PREVENTION IS BETTER THAN CURE!

  25. QUestions

  26. Thank you!