Web Application Security

Web Application Security Prof. Sukumar Nandi Indian Institute of Technology Guwahati Agenda Web Application basics Web Network Security Web Host Security Web Application Security Best Practices Questions? Web Application Basics Web Server Web Client Web Applications Application Databases Web Client How are they connected? Transport Response Web Apps Request Web Server n-tiers Databases 1

How are they connected? (contd.) Web Client (normally a browser) issues a request to the Web Server using HTTP/HTTPS. Web server processes the request and builds a web page using resources such as databases. This web page is returned to the Web Client, which it displays to the user. Examples Web Client Internet Explorer, Mozilla Web Server Apache, IIS Database MySQL, Oracle Firewall PIX, CheckPoint Network Security For Web application its host network is of prime importance. Web Application security will work only if its surrounding network infrastructure is safe. If an attacker is successful in taking down the Web application host network, then the rest is history ;-) 2

Network Security elements Router Security DDoS Security Firewalls Network Intrusion Detection System Host Intrusion Detection System Router Security Use ssh as opposed to Telnet for accessing the router. Close all unwanted services like http, ntp etc Add infrastructure ACLs to protect the routers themselves from malicious attacks. DDoS Security DDoS is a major problem and can take down incredibly large infrastructures. A DDoS attack consists of Zombie computers controlled by an attacker who conducts a distributed attack on a victim. DDoS attacks have know to take down large corporation like Yahoo and E-Bay. DoS and DDoS Attacks TCP SYN TCP ACK UDP, ICMP, TCP floods Fragmented Packets IGMP flood Spoofed and un-spoofed 3

Basics of a DDoS Attack Automated DDoS Attack DDoS client 1 Initiate scan 2 Vulnerable hosts are compromised DDoS handler DDoS handler DDoS handler Attacker 4 Further scanning for compromises 4 4 3 Attack tool installed on each compromised host DDoS agents DDoS Traffic 5 Massive DDoS attack launched 5 Victim Network 5 DoS Filtering Description default loopback RFC 1918 RFC 1918 RFC 1918 Net Test Testing devices IPv6 to IPv4 relay RFC 1918 nameservers End-node auto configuration Network 0.0.0.0 /8 127.0.0.0 /8 10.0.0.0 /8 172.16.0.0 /12 192.168.0.0 /16 192.0.2.0 /24 192.18.0.0 /15 192.88.99.0 /24 192.175.48.0 /24 169.254.0.0 /16 Firewall Firewalls are an essential requirement in today's networks. It makes it very easy to filter attacks based on IP, port, service etc Firewalls like Cisco PIX allow a huge level of low level customization to be able to fine tune it to even bits in the packet headers and even have capability to peer into the application layer. 4

Internet Router Policy Internet Router Configuration Ingress filtering: deny all rfc 1918 and special use addresses from entering the corporate network deny all traffic with an IP source address of the corporate network or branch networks permit all other traffic Egress filtering: permit only traffic with an IP source address of the corporate network and branch networks deny all other traffic access-list 133 deny ip host 0.0.0.0 any access-list 133 deny ip 127.0.0.0 0.255.255.255 any access-list 133 deny ip 10.0.0.0 0.255.255.255 any access-list 133 deny ip 172.16.0.0 0.15.255.255 any access-list 133 deny ip 192.168.0.0 0.0.255.255 any access-list 133 deny ip 192.0.2.0 0.0.0.255 any access-list 133 deny ip 169.254.0.0 0.0.255.255 any access-list 133 deny ip 240.0.0.0 15.255.255.255 any access-list 133 deny ip 144.254.0.0 0.0.255.255 any access-list 133 deny ip 171.71.32.0 0.0.0.31 any access-list 133 deny ip 192.150.42.0 0.0.0.31 any access-list 133 permit ip any any access-list 144 permit ip 144.254.0.0 0.0.255.255 any access-list 144 permit ip 171.71.32.0 0.0.0.31 any access-list 144 permit ip 192.150.42.0 0.0.0.31 any access-list 144 deny ip any any interface Serial 0/0 description To Internet ip access -group 133 in ip access -group 144 out Network IDS Network based Intrusion Detection Systems are used to detect various attacks at the network level itself. Positioning the NIDS is very important so it can see all the traffic on the network. NIDS like Snort are Signature based and those like PHAD are anomaly based. Network IDS (contd.) Anomaly based IDS have the ability to learn what is normal for the network in question and then tries to detect aberrations from this normality. Signature based IDS detect attacks try to detect signature patterns in the network traffic. 5

Host based IDS Protecting individual hosts is necessary. Sometimes internal computers might be the first point of attack of email based worms and viruses. A good patching system is also required. Security updates for software packages installed on the computer should be installed from time to time. Web Host Security Host Security? Host security refers to the security measures used to secure the computer hosting the web applications. Shut down unnecessary services which are not used e.g. RPC ports Have a good patch management system in place. Host Security (contd.) Host based IDS is a program which sits on the computer and probes for suspicious events at a process and sometimes even a system call level. Host based IDS provide an access edge level security by protecting the end hosts on the network. 6

Web Application Security What is so unique about web App. Sec N-BIOS HTTP(S) FTP RPC Firewall Web Server Data Base Server Uniqueness lies in the fact that Almost all E-Commerce applications are web application based banking, shopping Web application uses port 80 i.e. the HTTP port. Port 80 is almost NEVER blocked on the firewalls. Thus applications accessible via port 80 are the starting point for a web hacker. Are Web Applications Vulnerable? HTTP is a stateless protocol and inherently insecure Each HTTP request is discrete Application has to keep track of user session Trusting Browser input is a myth and so are these: The user will only send required input The user cannot manipulate drop-down lists The user cannot manipulate hidden fields Java scripts will take care of validation Using SSL is an airtight solution 7

Are Web Apps vulnerable? Attractive targets yielding high value results Credit Card Numbers Bank account information Confidential information Personal Email Conventional security solutions (SSL and Firewalls) not adequate Often developed in house - poor code and frequent updates Gartner: most of the cyber attacks were at the application level Web App vulnerability list Unvalidated parameters Broken Access Control Broken Account and Session Management XSS Flaws Buffer Overflows Command Injection Flaws Error handling Problems Web App Vulnerability list (contd.) Insecure Use of Cryptography Remote Administration Flaws Web and Application Server Misconfiguration 1. Un-validated Parameters HTTP requests from browsers to web apps URL, Querystring, Form Fields, Hidden Fields, Cookies, Headers Web apps use this information to generate web pages Attackers can modify anything in request WebScarab Key Points: Check before you use anything in HTTP request Canonicalize before you check Client-side validation is irrelevant Reject anything not specifically allowed Type, min/max length, character set, regex, min/max value 8

1. Unvalidated Parameters (contd.) Unvalidated input: Never trust input from a user Malicious user can tamper with anything and try to: Cause errors to occur and give up info Buffer overflow Modify parameters Common attacks: Modifying URL SQL Injection Cross Site Scripting Session hijacking with cookie modification 1. Unvalidated Parameters (contd.) Unvalidated input: SQL Injection A little more difficult Insert SQL statement where they do not sufficiently validate input Vulnerable CGI-code will forward the malicious statement to database Database is indifferent, executes the statement and sends the results back to the user 1. Unvalidated Parameters (contd.) Unvalidated input: SQL Injection example www.test.com/cgi-bin/productdesc.asp?category=10; CGI code will look like (don t worry about this part!): v_cat = request("category") #v_cat=10; sqlstr="select description FROM product WHERE category='" & v_cat & "'" set rs=conn.execute(sqlstr) Database will execute: SELECT description FROM product WHERE category=10; 1. Unvalidated Input (contd.) Unvalidated input: SQL Injection example If we give the category another value instead of the normal one: www.test.com/cgi-bin/productdesc.asp?category=10 UNION SELECT name,pwd FROM admins;-- CGI code will look like (don t worry about this part!): v_cat = request("category") # v_cat= 10 UNION SELECT name, pwd FROM admins;-- sqlstr="select description FROM product WHERE category='" & v_cat & "'" set rs=conn.execute(sqlstr) Database will execute: SELECT description FROM product WHERE category= 10 UNION SELECT name, pwd FROM admin;-- (-- is comment out the rest of syntax.) Got the admin username and password! 9

2. Broken Access Control Access control is how you keep one user away from other users information The problem is that many environments provide authentication, but don t handle access control well Many sites have a complex access control policy Insidiously difficult to implement correctly Key Points Write down your access control policy Don t use any id s that an attacker can manipulate Implement access control in a centralized module 3. Broken Account and Session Management Account Management Handling credentials across client-server gap Backend authentication credentials too Session Management HTTP is a stateless protocol. Web apps need to keep track of which request came from which user Brand sessions with an id using cookie, hidden field, URL tag, etc Key Points Keep credentials secret at all times Use only the random sessionid provided by your environment 4. Cross-Site Scripting (XSS) Flaws Web browsers execute code sent from websites Javascript Flash and many others haven t really been explored But what if an attacker could get a website to forward an attack! Stored web application stores content from user, then sends it to other users Reflected web application doesn t store attack, just sends it back to whoever sent the request Key Points Don t try to strip out active content too many variations. Use a positive specification. 4. XSS (Contd.) Unvalidated input: Cross site scripting Hidden Html code/ Java script code injection Similar to SQL Injection Cross-Site-Scripting may not be directly against your website but against your clients 4 easy steps! 1. Locate Web page with unchecked input 2. Embed poisoned link or scripts to Web page 3. Send the pages to client to collect information using spamor putting in forum 4. Collect the Web users client information or further for session hijacking Few people check html/javascript codes, sometime the links are unicoded, hard to read 10

5. Buffer Overflows Web applications read all types of input from users Libraries, DLL s, Server code, Custom code, Exec C and C++ code is vulnerable to buffer overflows Input overflows end of buffer and overwrites the stack Can be used to execute arbitrary code Key Points Don t use C or C++ Be careful about reading into buffers Use safe string libraries correctly 6. Command Injection Flaws Web applications involve many interpreters OS calls, SQL databases, templating systems Malicious code Sent in HTTP request Extracted by web application Passed to interpreter, executed on behalf of web app Key Points Use extreme care when invoking an interpreter Use limited interfaces where possible (PreparedStatement) Check return values 11

7. Error Handling Problems Errors occur in web applications all the time Out of memory, too many users, timeout, db failure Authentication failure, access control failure, bad input How do you respond? Need to tell user what happened (no hacking clues) Need to log an appropriate (different) message Logout, email, pager, clear credit card, etc Key Points: Make sure error screens don t print stack traces Design your error handling scheme Configure your server Application Hacking What do these variables do? Application Hacking Variable IB -> IC Variable IB&F22 -> IB&F112 Different variable, different error 12

Full path names revealed Table Name Field Name Database Name 13

8. Insecure Use of Cryptography Use cryptography to store sensitive information Algorithms are simple to use, integrating them is hard Key Points Do not even think about inventing a new algorithm Be extremely careful storing keys, certs, and passwords Rethink whether you need to store the information Don t store user passwords use a hash like SHA-256 The master secret can be split into two locations and assembled Configuration files, external servers, within the code 9. Remote Administration Flaws Many sites allow remote administration Very powerful, often hidden interfaces Difficult to protect Key Points Eliminate all administration over the Internet Separate the admin application from the main app Limit the scope of remote administration Consider strong authentication Smart card or token 10. Web and Application Server Mis-configuration All web and application servers have many security-relevant configuration options Default accounts and passwords Unnecessary default, backup, sample apps, libraries Overly informative error messages Misconfigured SSL, default certificates, self-signed certs Unused administrative services Key Points: Keep up with patches (Code Red, Slammer) Use Scanning Tools (Nikto, Nessus) Harden your servers! E-Commerce Security Best Practices 14

How to protect Web Apps? How to stop Web application attacks Error message customization Restricted access to sensitive information Patch Web servers Remove the sensitive page from Google Regularly perform application test Deploy a web application firewall Deploy IPS that will analyze application level Questions? 15