MOBILE COMPUTING. Web Applications. (INTRODUCTION, Architecture and Security) Lecture-10 Instructor : Mazhar Hussain

Transcription

1 MOBILE COMPUTING Web Applications (INTRODUCTION, Architecture and Security) 1 Lecture-10 Instructor : Mazhar Hussain

2 INTRODUCTION TO WEB Web features Clent/Server HTTP HyperText Markup Language URL addresses Web server - a computer program that is responsible for accepting HTTP requests from clients and serving them HTTP responses Web application - a dynamic extension of a web or application server 2

3 WEB APPLICATIONS & COMPONENTS Two types of web applications: Presentation-oriented (HTML, XML pages) Service-oriented (Web services) Web components provide the dynamic extension capabilities for a web server: Java servlets JSP pages Web service endpoints 3

4 WEB APPLICATION INTERACTION [client] sends an HTTP request to the web server [web server] HTTP request HTTPServletRequest This object is delivered to a web component, which can interact with JavaBeans or a DB to generate dynamic content [web component] generates an HTTPServletResponse or pass the request to another web component [web server] HTTPServletResponse HTTP response [web server] returns HTTP response to the client 4

5 WEB APPLICATION INTERACTION 5

6 WEB COMPONENTS Servlets - Java classes that dynamically process requests and construct responses JSP pages - text-based documents that execute as servlets but allow a more natural approach to creating static content Appropriate usage Servlets - service-oriented applications, control functions JSP - generating text-based markup (HTML, SVG, WML, XML) 6

7 JAVA WEB APPLICATION TECHNOLOGIES Java Servlet technology is the foundation of 7 all the web application technologies

8 WEB CONTAINERS Web components are supported by the services of a runtime platform called a web container In J2EE, a web container "implements the web component contract of the J2EE architecture Web container services: request dispatching security concurrency life-cycle management naming, transactions, APIs 8

9 WEB CONTAINER EXAMPLES Non-commercial Apache Tomcat Jetty Commertial Sun Java System Application Server BEA WebLogic Server Oracle Application Server WebSphere Open source JBoss 9

10 DEPLOYMENT Web components have to be installed or deployed to the web container Aspects of web application behaviour can be configured during application deployment The configuration information is maintained in a XML file called a web application deployment descriptor 10

11 WEB APPLICATION DEVELOPMENT A web application consists of: Web components Static resource files (such as images) Helper classes and libraries The process for creating and running a web application is different from that of traditional stand-alone Java classes 11

12 DEVELOPMENT CYCLE 1. Develop the web component code 2. Develop the web application deployment descriptor 3. Compile the web application components and helper classes referenced by the components 4. Optionally package the application into a deployable unit 5. Deploy the application into a web container 6. Access a URL that references the web application 12

13 WEB MODULES According to Java EE architecture and Java Servlet Specification: Web components and static web content files such as images are called web resources A web module is the smallest deployable and usable unit of web resources Web module corresponds to a web application A web module has a specific structure 13

14 WEB MODULE STRUCTURE The top-level directory of a web module is the document root of the application The document root contains: JSP pages client-side classes client-side archives static web resources 14

15 WEB MODULE STRUCTURE The document root contains a subdirectory /WEB-INF/ web.xml: web application deployment descriptor lib: JAR archives of libraries called by server-side classes 15

16 WEB MODULE STRUCTURE classes: server-side classes: servlets utility classes JavaBeans components tags: tag files, which are implementations of tag libraries 16

17 WEB APPLICATION ARCHITECTURE 17

18 CLIENT SERVER MODEL 18

19 SERVER APPLICATIONS (SOFTWARE) Management and maintenance of Data including User login data Application data Data processing Centralized Access via Login 19

20 CLIENT APPLICATIONS (SOFTWARE) Provides user interface Stores some settings Can do some data processing Little to no application data storage Same view of data no matter where you login 20

21 CLIENT-SERVER ADVANTAGES Centralized Data Storage No data redundancy (no duplication of data) Reduces data dependencies If data is stored on each user s system and each system is different than data depends on how the user system is designed Data can not be shared easily if such dependencies exist 21

22 CLASSIC EXAMPLE: EARLY BANKING SYSTEMS Network: Local Area Network (LAN) covering local office branch. Server: Mainframe-like server in the back running custom banking system Client: Windows PC with client interface for each bank teller. Data is the same no matter what teller you go to. Data is NOT the same if you go to another branch unless servers exchanged some data at night. 22

23 CLASSIC EXAMPLE: EARLY BANKING SYSTEMS The Obvious Future: Change the LAN to a wide area network covering all the branches. Get rid of the individual servers at each branch Have clients connect to central server where ALL the banking data is stored. 23

24 CLASSIC EXAMPLE: EARLY BANKING SYSTEMS The Obvious Problems: Large banks could have thousands of tellers connecting to the central server. Combining data from all branches requires severs with lots of storage capacity. Branch data could be stored in different formats. Lack of Standardization. 24

25 3-TIERED SYSTEMS 25

26 3-TIERED SYSTEM Database Tier (Database Server) Data storage and low level data manipulation Server Tier (Application Server) Manage client connections and data processing Client Tier (Client Software installed locally) User interface and some data processing 26

27 ADVANTAGE OF 3-TIER SYSTEMS Central Database Server accessed by multiple Application Servers In turn, each Application Server could independently manage thousands of users Database Server is specially designed to do its job Database Operations: Update, Insert, Remove, etc. Lots of disk storage and memory needed Application Servers can be added to support more users or DIFFERENT APPLICATIONS Server Operations: Complex applicationdependent computations 27

28 INTERNET VS. WWW Internet is the infrastructure that makes the WWW work. Packet Switching TCP/IP Protocol Physical Infrastructure Fiber-optics lines, wires Satellites, Cable Modems Routers, Hubs, Network Cards, WiFi systems, etc. WWW is just one of many virtual networks built on the Internet. Websites: http, https, etc. pop, imap, etc. Other systems: ftp, instant messaging, etc. Note: Even to this day companies have private virtual networks that use the Internet, but are proprietary, locked-down. 28

29 WWW ULTIMATE CLIENT- SERVER SYSTEM Already Standardized Built on the Widest Area Network you could imagine, i.e., The Internet Standardized Clients that are free to use IE, Firefox, Safari, etc. Lots of Servers already in place Apache, Windows Server (IIS), etc. Database Servers Umm, this was initially missing 29

30 FIRST WEB APPLICATIONS 1993 Rob McCool proposed a framework called CGI (Common Gateway Interface) Data passed from a web browser to the server GET - passed via URL variables POST - passed via HTML forms Web server daemon (httpd) could then make remote system calls Example Web server could run a C++ program and write the output to public HTML folder Web server would send response back with location of the output. 30

31 FIRST WEB APPLICATIONS Using CGI, web server could run C++ programs Perl Programs Fortran Programs C++ has library functions that allow you to connect to a number of different databases: Oracle Sybase DB2 31

32 FIRST WEB APPLICATIONS Problem: To develop web applications you need to know Exactly how your server is configured HTML forms GET and POST conventions C++ database libraries SQL language 32

33 FIRST MAJOR IMPROVEMENT 1995 JJ Allaire developed a hack that allowed a web servers to communicate with other systems, namely a database system. Key: Instead of using a middle-man C++, Perl, Java, etc. Developer could directly add code to the their web pages Using a special Markup Language, this code could be embedded in any web page. Worked seamlessly with HTML forms Server process code directly 33

34 WEB APPLICATION SECURITY 34

35 OVERVIEW Background Web app vulnerabilities Securing web apps 35

36 BACKGROUND 36

37 HTTP Hypertext Transfer Protocol Hypertext Transfer Protocol (HTTP) is a communications protocol for the transfer of information on intranets and the World Wide Web. Its original purpose was to provide a way to publish and retrieve hypertext pages over the Internet. Server ( ) Port: 80 Client PC ( ) Request Response 37

38 HTTP REQUEST - GET Form data encoded in the URL Most common HTTP method used on the web Should be used to retrieve information, not for actions that have side-effects 38

39 HTTP REQUEST - GET GET HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv: ) Gecko/ Firefox/ Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*; q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: 39

40 HTTP REQUEST - GET 2coff%3D1%26rls%3DGGLG%252CGGLG%253A %252CGGLG%253Aen%26q%3Dhttp%253A%252F%252Fwww.google.com%252Fsearch%253Fhl %253Den%2526lr%253D%2526c2coff%253D1%2526rls%253DGGLG%25252CGGLG%25253A %25252CGGLG%25253Aen%2526q%253Dhttp%25253A%25252F%25252Fwww.google.com%252 52Fsearch%25253Fsourceid%25253Dnavclient%252526ie%25253DUTF- 8%252526rls%25253DGGLG%25252CGGLG%25253A %25252CGGLG%25253Aen%252526q%25253Dhttp% A% F% Fwww% Egoogle% Ecom% Fsearch% Fsourceid% Dnavclient% i e% dutf% d8% rls% dgglg% cgglg% a2005% D26% CGGLG% Aen% q% Dhttp% A% F% Fuk2% Emultimap% Ecom% Fmap% Fbro wse% ecgi% fclient% dpublic% gride% d% D0% E12640% GridN% D51% E50860% lon% D% D0% E12640% lat% D51% E50860% search% Fresult% DLondon% CGreater% London% db% Dfreegaz% cidr% Fclient% Dnone% lang% D% place% DLondon% CGreater% BLondon% pc% D% advanced% D% client% Dpublic% addr2% D% quicksear ch% dlondon% addr3% d% scale% d % addr1% D%2526btnG%253DSearch%26btnG%3DSearch&btnG=Search 40

41 HTTP REQUESTS - POST Data is included in the body of the request. Should be used for any action that has side-effects Storing/updating data, ordering a product, etc 41

42 HTTP REQUESTS - POST POST HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv: ) Gecko/ Firefox/ Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: catid=1 42

43 FAMOUS QUOTE OF THE DAY Every program has at least two purposes: the one for which it was written, and another for which it wasn't. -Alan J. Perlis 43

44 GET V. POST SECURITY There information contained in parameters can tell a user a lot about how your application works GET parameters are easily visible in the address bar POST parameters are hidden from the average user Users can still view source code Users can still view the packets Users can still intercept & modify web requests 44

45 WEB SITES No applications Static pages Hard coded links Browser Web Server 45

46 WEB APPLICATIONS Web Services Very complex architectures, multiple platforms, multiple protocols Web Application HTTP Network Wireless Web Servers Presentation Layer Application Server Business Logic Database Server Customer Identification Browser Media Store Content Services Access Controls Transaction Information Core Business Data 46

47 WEB APPLICATIONS BREACH THE PERIMETER Internet DMZ Trusted Inside IIS SunOne Apache ASP.NET WebSphere Java SQL Oracle DB2 HTTP(S) Browser Allows HTTP port 80 Allows HTTPS port 443 Firewall only allows applications on the web server to talk to application server. Firewall only allows application server to talk to database server. Corporate Inside 47

48 WHY WEB APPLICATION VULNERABILITIES OCCUR Security Professionals Don t Know The Applications As a Network Security Professional, I don t know how my companies web applications are supposed to work so I deploy a protective solution but don t know if it s protecting what it s supposed to. The Web Application Security Gap Application Developers and QA Professionals Don t Know Security As an Application Developer, I can build great features and functions while meeting deadlines, but I don t know how to develop my web application with security as a feature. 48

49 WEB APPLICATION VULNERABILITIES If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. -Weinberg's Second Law 49

50 WEB APPLICATION VULNERABILITIES Technical Vulnerabilities Result of insecure programming techniques Mitigation requires code changes Detectable by scanners p0wned )</ script>&price= Logical Vulnerabilities Result of insecure program logic Most often to due to poor decisions regarding trust Mitigation often requires design/architecture changes Detection often requires humans to understand the context 50

51 WEB APPLICATION VULNERABILITIES Web application vulnerabilities occur in multiple areas. Platform Known Vulnerabilities Administration Extension Checking Common File Checks Data Extension Checking Backup Checking Directory Enumeration Path Truncation Hidden Web Paths Forceful Browsing Application Application Mapping Cookie Manipulation Custom Application Scripting Parameter Manipulation Reverse Directory Transversal Brute Force Application Mapping Cookie Poisoning/Theft Buffer Overflow SQL Injection Cross-site scripting 51

52 WEB APPLICATION VULNERABILITIES Platform Known Vulnerabilities Platform: Known vulnerabilities can be exploited immediately with a minimum amount of skill or experience script kiddies Most easily defendable of all web vulnerabilities MUST have streamlined patching procedures 52

53 WEB APPLICATION VULNERABILITIES Administration Extension Checking Common File Checks Data Extension Checking Backup Checking Directory Enumeration Path Truncation Hidden Web Paths Forceful Browsing Administration: Less easily corrected than known issues Require increased awareness More than just configuration, must be aware of security flaws in actual content Remnant files can reveal applications and versions in use Backup files can reveal source code and database connection strings 53

54 WEB APPLICATION VULNERABILITIES Application Application Mapping Cookie Manipulation Custom Application Scripting Parameter Manipulation Reverse Directory Transversal Brute Force Application Mapping Cookie Poisoning/Theft Buffer Overflow SQL Injection Cross-site scripting Application Programming: Common coding techniques do not necessarily include security Administration Input is assumed to be valid, but not tested Unexamined input from a browser can inject scripts into page for replay against later visitors Unhandled error messages reveal application and database structures Unchecked database calls can be piggybacked with a hacker s own database call, giving direct access to business data through a web browser 54

55 HOW TO SECURE WEB APPLICATIONS Incorporate security into the lifecycle Apply information security principles to all software development efforts Educate Issue awareness, Training, etc 55

56 HOW TO SECURE WEB APPLICATIONS Incorporating security into lifecycle Integrate security into application requirements Including information security professionals in software architecture/design review Security APIs & libraries (e.g. ESAPI, Validator, etc.) when possible Threat modeling Web application vulnerability assessment tools 56

57 HOW TO SECURE WEB APPLICATIONS Educate Developers Software security best practices Testers Methods for identifying vulnerabilities Security Professionals Software development, Software coding best practices Executives, System Owners, etc. Understanding the risk and why they should be concerned 57

58 QUESTIONS/COMMENTS? 58