Writing Secure Web Applications


Writing Secure Web Applications Andreas Wiegenstein - Chief Technical Officer >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Table of Contents ƒ Security Statements ƒ Know Your Enemy - How Hackers "Work" ƒ Web Application Characteristics ƒ Attack & Defense - Threats and Best Practices ƒ General Best Practices ƒ References and Further Reading ƒ Q&A >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Security Statements Know Your Enemy - How Hackers "Work" Web Application Characteristics Attack & Defense - Threats and Best Practices General Best Practices References and Further Reading Q&A >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Security Statements The challenge: ƒ In order to secure an IT system, all of its components, functions and threats must be understood ƒ In order to break an IT system, only one flaw in any of its components/functions has to be found The problem: ƒ Each new technology brings with it new vulnerabilities ƒ Firewalls, Intrusion Detection Systems and Encryption don't make a secure IT system >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Security Statements Know Your Enemy - How Hackers "Work" Web Application Characteristics Attack & Defense - Threats and Best Practices General Best Practices References and Further Reading Q&A >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Types of attackers: ƒ Hackers ƒ Script Kiddies ƒ Social Engineers ƒ (Disgruntled) Employees >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Types of attackers: Hackers ƒ highly-skilled, but few in numbers ƒ can find new security holes in systems ƒ can find new types of attack ƒ can write tools ƒ break mostly into "challenging" systems ƒ publish/trade weaknesses ¾ Hackers look for new security weaknesses >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Types of attackers: Script Kiddies ƒ low-skilled, but numerous ƒ use other peoples` tools and known exploits to break into systems ƒ multiply known attacks against vulnerable systems ƒ goal is to "0WN" as many machines as possible ƒ attack systems at will (with automated scripts) ¾ Script Kiddies look for systems vulnerable to known exploits ! Advice: Keep your systems patched >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Types of attackers: Social Engineers ƒ very good technical as well as social skills ƒ attacks are primarily directed against humans ('wetware') ƒ trick employees in helping them to bypass security systems ƒ use deception, persuasion and IT know-how to gather useful information ƒ goal is usually data theft ¾ Social Engineers look for clues on which they can base their attacks. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Types of attackers: (Disgruntled) Employees ƒ use insider knowledge to gain system access ƒ motivated by curiosity or anger ¾ Employees usually look for HR information (e.g. salary) ¾ Disgruntled employees will try to damage the IT infrastructure >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Types of attackers – Summary ƒ different types of attackers ƒ different motivations ƒ different resources ¾ every company is a potential target ¾ new vulnerabilities can be discovered every day ¾ exploits spread quickly ¾ every unnecessary information in a web app can be dangerous >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Stages of an attack ƒ Reconnaissance ƒ Data analysis ƒ Attack preparation ƒ Attack ƒ Clean up >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Stages of an attack - Reconnaissance ƒ download HTML application ƒ save HTTP stream ƒ check forums for developer questions ƒ read WHOIS data ƒ use search engines to find "hidden" files on the target server ƒ ... >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Stages of an attack - Data analysis ƒ search for comments in the HTML code ƒ identify web server & OS ƒ look for meta information (e.g. author) ƒ search for server-side source code ƒ determine all application input ƒ deduce overall security by inducing errors ƒ analyze the application logic >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Stages of an attack - Attack preparation ƒ determine how the applications reacts to unexpected input ƒ try tricking the application logic ƒ deduce attack patterns >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Stages of an attack - Attack Stages of an attack - Clean up ƒ remove entries in log files ƒ remove other traces ƒ possibly install a backdoor ! Advice for hacked sites: ¾ secure the hard drive ¾ install everything from scratch >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Know Your Enemy - How Hackers "Work" Stages of an attack – Summary Be very careful ƒ which piece of data makes it into productive code ƒ to remove old code/pages ƒ what questions you ask in forums ƒ to exhaustively test your applications >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Security Statements Know Your Enemy - How Hackers "Work" Web Application Characteristics Attack & Defense - Threats and Best Practices General Best Practices References and Further Reading Q&A >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Web Application Characteristics Remote Client (Browser) ƒ requests resources and sends responses Data transfer through an internet/intranet ƒ data is sent through other (uncontrolled) servers Web server, OS, Backend system/database ƒ API ƒ data storage ƒ Text/MIME repository Web application ƒ processes client data ƒ requests server data (through API calls) >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Web Application Characteristics Remote GUI (Browser) Could be any software able to send requests and receive responses Threats: ƒ Javascript may not work, hence input validation might not be possible ƒ client might change "unchangeable" data ƒ hidden fields ƒ select box values ƒ Cookies ƒ user agent ƒ Referrer ƒ ... ƒ client might ignore length restrictions ƒ client might add or remove data >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Web Application Characteristics Data transfer through internet/intranet Threats: ƒ data might be read or changed en route ƒ someone else might assume the identity of the server HTTPS ƒ provides Confidentiality, Integrity, Authenticity (CIA) ! Caveat: ƒ The quality of encryption can vary ƒ Client authentication is not guaranteed ƒ HTTPS might slip malicious code past a Firewall or IDS ƒ HTTPS protects the data transfer between client and server - nothing else >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Web Application Characteristics Web server, OS, Backend system/database ! Most IT systems are not secure by default. Threats: ƒ system might not be configured securely ƒ system might run unnecessary (dangerous) services/examples ƒ system might be buggy ! Advice: ƒ have an expert configure the systems for your needs ƒ have an expert harden the systems ƒ first test, then install patches ƒ have an independent team run a penetration test ƒ constantly repeat those steps >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Web Application Characteristics Web application Threats: ƒ unexpected user input ƒ manipulated data from the database/configuration file ƒ manipulated text from a text repository ! Advice: ƒ don't trust any input ƒ use positive filters: only allow what's valid ƒ validate all input for its destined context The danger of malicious input is only clear and present in a certain context. Only the web application knows that context. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Web Application Characteristics Summary ƒ all client attacks against a web app must be carried out through the HTTP(S) protocol ƒ validating all input is the key to web application security ƒ data transfer in an intranet/internet must be protected ƒ keeping an IT system secure is an ongoing process, not a single action Remember: one flaw is all the attacker needs… >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Security Statements Know Your Enemy - How Hackers "Work" Web Application Characteristics Attack & Defense - Threats and Best Practices General Best Practices References and Further Reading Q&A >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices ƒ In-Band Signaling ƒ Cross-Site Scripting ƒ SQL injection ƒ OS command injection ƒ Forceful Browsing ƒ Session Hijacking ƒ Fault Induction ƒ Directory Traversal ƒ Cookie Poisoning >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling is the act of transporting metadata and control instructions inside the regular data sent. Threat: ƒ an application fails to separate the metadata and control instructions from the data, resulting in Unwanted Command Execution. Risk: ƒ arbitrary command execution on the server Best practices: ƒ metadata and control instructions must be escaped. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - Cross-Site Scripting (XSS) Threat: ƒ an attacker manages to place HTML content into a page someone else will open at a later time, possibly in a different security context. Risk: ƒ Tampering with Data ƒ execution of ActiveX commands ƒ Information Disclosure ƒ Stolen Cookie (SSO2 ticket) ƒ Stolen data (Redirected forms) >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - Cross-Site Scripting (XSS) [ cont’d ] Examples: ƒ an online application viewed in a corporate intranet ƒ a message posted to an online forum ƒ an administrator opening a log file with a browser Best practices: ƒ escape HTML/Javascript control characters < > & " ' ( ) . ! Caveat: ƒ attack methods vary depending on context Note: ƒ XSS attacks the client, not the server >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - Cross-Site Scripting (XSS) example code Part of the companies intranet application: public void doContent(...) { ... String s; if ((s = getUsernameByID("userid")) != null) { response.write("
Applicant:" + s + ""); } ... } Supposed output:
Applicant:Smith >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - Cross-Site Scripting (XSS) example attack Data entered in the field "user name": Smith >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - Cross-Site Scripting (XSS) attack result HTML output containing the applicants input, rendered in the companies’ intranet:
Applicant: Smith Visible output: Applicant: Smith >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - Cross-Site Scripting (XSS) secure code Security enhanced function: public void doContent(...) { ... String s; if ((s = getUsernameByID("userid")) != null) { s = StringUtils.encodeToHTML(s, 50); response.write("
Applicant:" + s + ""); } ... } >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - Cross-Site Scripting (XSS) SAP API’s SAP System WAS/ABAP: cl_http_utility->escape_html EP5/EP6: several methods in class StringUtils HTMLB: implicit protection Web Dynpro: implicit protection >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - SQL injection Threat: ƒ An attacker manages to place SQL commands into an input string that is used as a parameter in a database query. Risk: ƒ Tampering with Data ƒ data can be changed/deleted without authorization ƒ Information Disclosure ƒ data can be read without authorization ƒ Denial of Service ƒ data can be deleted without authorization ƒ Elevation of Privilege ƒ depending on the database, system commands can be executed >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - SQL injection [ cont’d ] Best practices: ƒ validate input ƒ remove/escape the character ' in strings >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - SQL injection example code ... cUser = Request('user'); Conn = Server.CreateObject("ADODB.Connection"); Conn.Open(pDBName); inSQL = "SELECT * FROM User WHERE UID='" + cUser + "'"; exSQL = sql_Exec(Conn, inSQL); var bUserConfirmed = false; if ((exSQL != null) && (!exSQL.EOF)) { bUserFound = true; } ... >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - SQL injection example data (valid credentials) URL http://www.example.com/hack.asp?user=smith23 SQL SELECT * FROM User WHERE UID='smith23' > Welcome back, Mr. Smith! (invalid credentials) URL http://www.example.com/hack.asp?user=bad_guy SQL SELECT * FROM User WHERE UID='bad_guy' > Please provide the correct credentials. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signaling - SQL injection example attack and result (#1: unexpected "credentials") URL http://www.example.com/hack.asp?user=%27+OR+%27A%27=%27A SQL SELECT * FROM User WHERE UID='' OR 'A'='A' > Welcome back, Mr. Anderson! (#2: nasty input) URL http://www.example.com/hack.asp?user=%27;DROP+TABLE+User; SQL SELECT * FROM User WHERE UID='';DROP TABLE User; > [Denial of Service] >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices In-Band Signalling - OS command injection Threat: ƒ An attacker manages to place OS commands into an input string that is used as part of a system command issued by the web app. Risk: ƒ complete system compromise Best practices: ƒ Don't execute system commands from a web app. ƒ If you must execute commands, don't base them on user input. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Forceful Browsing Threat: ƒ A resource that is not reachable through normal application logic is a accessed by directly navigating to its URL. Risk: ƒ (resource is a document) ƒ Information Disclosure ƒ (resource is a page) ƒ Information Disclosure ƒ Elevation of Privilege Best practices: ƒ All sensitive resources must be protected by strict access control. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Forceful Browsing examples Application URLs A) http://www.example.com/page1.html B) http://www.example.com/2003/report.pdf C) http://www.example.com/2003/report.pdf Deductions A) http://www.example.com/page2.html B) http://www.example.com/2004/report.pdf C) http://www.example.com/2003/ >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Forceful Browsing SAP System ITS: Pages have coded IDs. WAS: Authorization is per application. Authorized users can access all pages. EP5/EP6: Build-in access control mechanism for iViews/components. Some resources might be accessible. Web Dynpro: Authorized users can access all views. ! Note: MIME files are always accessible. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Session Hijacking Threat: ƒ An attacker might deduce another users session ID from his own. Risk: ƒ Spoofing ƒ Tampering With Data ƒ Information Disclosure ƒ Elevation of privilege Best practices: ƒ Use proven industry standards that have been reviewed by experts. ƒ If you must create your own session management, consult a cryptographic expert. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Session Hijacking example Original Session ID (stored in a cookie) "sid=u0000123" Result "Welcome Mr. Smith, you have no new messages" Manipulated ID "sid=u0000124" Result "Welcome Mr. Anderson, you have 5 new messages" ! All SAP systems provide secure session management. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Fault Induction Threat: ƒ Error conditions are forced by manipulated input in order to deduce information. Risk: ƒ Information Disclosure Best practices: ƒ Use proper input validation. ƒ Display only general messages like "Invalid input" or "An error has occurred." >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Fault Induction example Application URL: http://www.example.com/main.asp?disp=start.html Manipulated URL: http://www.example.com/main.asp?disp=#%;xy? Application output: An Error has occurred: The file "c:\app\html\#%;xy?" could not be found. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Directory Traversal Threat: ƒ Input that is used to look up files is modified in order to access another file. Risk: ƒ Information Disclosure ƒ Denial of Service Best practices: ƒ Use a positive filter to define all allowed resources. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Directory Traversal example Application URL http://www.example.com/main.asp?disp=start.html (Information deduced from Fault Induction) Resource "start.html" resides in the folder "c:\app\html" Exploit http://www.example.com/main.asp?disp=..\..\winnt\win.ini >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Cookie Poisoning Threat: ƒ Application data stored in a cookie might be manipulated. Risk: ƒ Tampering with Data ƒ Information Disclosure Best practices: ƒ Don't rely on data stored in cookies (they are input) ... ƒ ...unless this data is protected by cryptography (SSO2 ticket) >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Cookie Poisoning example Shopping carts used to store pricing information in cookies. (Part of a shopping cart applications' cookie) item1_ID=12369&item1_pr=27,95&item2_ID=10334&item2_pr=19,95 > Total Amount: $47,90 (Manipulated cookie) item1_ID=12369&item1_pr=0,95&item2_ID=10334&item2_pr=1,95 > Total Amount: $2,90 >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Attack & Defense - Threats and Best Practices Summary ƒ all attacks shown have one thing in common: unexpected input ƒ the best way to protect against unexpected input is by using positive filters: only allow what's valid ! Advice ƒ validate all input ƒ only rely on server side data validation ƒ reduce your input to its simplest form : canonicalization ! Only use the examples above to test application security when you have written permission by an authorized person to do so. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Security Statements Know Your Enemy - How Hackers "Work" Web Application Characteristics Attack & Defense - Threats and Best Practices General Best Practices References and Further Reading Q&A >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein General Best Practices Management: ƒ Create a security policy regarding software development ...and make people read and follow it. ƒ Perform risk analysis of all IT components on a regular basis ...to know what's at stake for your company. ƒ Send your development staff to security trainings on a regular basis. ƒ Make security a priority ...because if you don't find the bugs in your systems, someone else will. Remember: one flaw is all the attacker needs… >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein General Best Practices Software Development: ƒ Make security a part of your development cycle, not an afterthought. ƒ Make sure your developers receive sufficient training. ƒ When contracting consultants make sure they follow your security policy. ƒ Perform security reviews by an internal team. ƒ Have your IT systems and applications reviewed by an independent (external) team. >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Security Statements Know Your Enemy - How Hackers "Work" Web Application Characteristics Attack & Defense - Threats and Best Practices General Best Practices References and Further Reading Q&A >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein References and Further Reading Application security: ƒ John Viega, Gary McGraw "Building Secure Software: How to Avoid Security Problems the Right Way" ƒ Michael Howard, David LeBlanc "Writing Secure Code, Second Edition Social engineering: ƒ Kevin Mitnick, William Simon, Steve Wozniak "The Art of Deception: Controlling the Human Element of Security" >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Security Statements Know Your Enemy - How Hackers "Work" Web Application Characteristics Attack & Defense - Threats and Best Practices General Best Practices References and Further Reading Q&A >>>> © Virtual Forge 2004, SAP TechEd, SDN101, Writing Secure Web Applications / Andreas Wiegenstein Q & A Thank you for your attention.
还剩58页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 5 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

lidongguo

贡献于2015-11-12

下载需要 5 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf