1. Lecture-8 Instructor : Mazhar Hussain
Mobile Computing
Web Applications
(Introduction, Architecture and Security)
Lecture-8
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

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

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

5. Web Application Interaction

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)

7. Java Web Application Technologies
Java Servlet technology is the foundation of 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

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

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

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

12. Development Cycle Develop the web component code
Develop the web application deployment descriptor
Compile the web application components and helper classes referenced by the components
Optionally package the application into a deployable unit
Deploy the application into a web container
Access a URL that references the web application

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

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

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

16. Web Module Structure classes: server-side classes: servlets
utility classes
JavaBeans components
tags: tag files, which are
implementations of
tag libraries

17. Web Application Architecture

18. Client Server Model

19. Server Applications (Software)
Management and maintenance of Data including
User login data
Application data
Data processing
Centralized
Access via Login

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

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

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.

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.

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.

25. 3-Tiered Systems

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

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 application-dependent computations
Lots of processor power needed

28. Internet vs. WWW
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.
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.

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

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.

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

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

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

34. Web Application Security

35. Overview
Background
Web app vulnerabilities
Securing web apps

36. Background

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
HTTP is called a stateless protocol because each request is processed independently, without any knowledge of the requests that came before it.
Client PC
( )
Request
Response

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
REST is a term coined by Roy Fielding in his Ph.D. dissertation [1] to describe an architecture style of networked systems. REST is an acronym standing for Representational State Transfer.

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:

40. HTTP Request - GET
26%2CGGLG%3Aen&q=http%3A%2F%2Fwww.google.com%2Fsearch%3Fhl%3Den%26lr%3D%26c 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

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…

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

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
A big part of web application security testing involves attempts to force an application to function in a way it was not intended to.
Alan Jay Perlis was an computer scientist known for his pioneering work in programming languages and the first recipient of the Turing Award (nobel prize of computing)

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

45. Web Sites No applications Static pages Hard coded links Browser
Web Server

46. Web Applications
Very complex architectures, multiple platforms, multiple protocols
Network
HTTP
Web Application
Web Services
Application Server
Business Logic
Content Services
Database Server
Customer Identification
Access Controls
Transaction Information
Core Business Data
Web Servers
Presentation Layer
Media Store
Wireless
Main speaking points:
- Now we no longer have websites, we have web applications
- Web applications reside on multiple systems in distributed architectures
- Three tiers (presentation, logic, data)
- Use sophisticated programming languages and architectures
- Corporate and customer data moved to the computing edge
- Edge extended to cellphones, pda’s, mobile sales force solutions, inventory management systems, etc.
Browser

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

48. Why Web Application Vulnerabilities Occur
The Web Application
Security Gap
Application Developers and QA Professionals Don’t Know Security
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.”
“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.”
Main Speaking Points:
There is a lack of awareness of application vulnerabilities in security departments.
Security Departments scrutinize the desktop, the network, and even the web servers, but the web application escapes their measures.
Even in departments that want to audit for web application vulnerabilities, the lack of effective tools has made it impractical
As a result, Certification and Accreditation programs rarely examine the web application
In fact, the entire development cycle is usually missing from security procedures and controls
This illustrates the fundamental gap between security and development, which creates these web application vulnerabilities
Many traditional information security practitioners are ill-equipped to
mitigate application security issues
– Little to no experience coding
– No experience coding in “modern” enterprise environments like .NET and J2EE
– Understand that there are risks, but not in a position to address them

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

50. Web Application Vulnerabilities
Technical Vulnerabilities
Result of insecure programming techniques
Mitigation requires code changes
Detectable by scanners
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

51. Web Application Vulnerabilities
Web application vulnerabilities occur in multiple areas.
Application
Application Mapping
Cookie Manipulation
Custom Application Scripting
Parameter Manipulation
Reverse Directory Transversal
Brute Force
Cookie Poisoning/Theft
Buffer Overflow
SQL Injection
Cross-site scripting
Administration
Extension Checking
Common File Checks
Data Extension Checking
Backup Checking
Directory Enumeration
Path Truncation
Hidden Web Paths
Forceful Browsing
Platform
Main Speaking Points:
-Web Application vulnerabilities occur in different areas of the web application.
[Note: Start at bottom of the screen]
-The web server itself is subject to a variety of known vulnerabilities, all of which must be readily patched for.
The actual administration and management of the server and contents is very important
A misconfigured server or poorly managed content can permit system file and source code disclosure
The application itself is of the utmost importance.
It too can inadvertently reveal source code and system files, and even allow full system access.
It can mistakenly allow replay attacks against your customers.
It could allow a hacker to impersonate your customers.
In addition it is the web application that interacts with the database to manage and tracks customer information and store business and transaction information .
One slip-up in the web application can expose the entire system and database, right through a web browser, right over port 80.
Known Vulnerabilities

52. Web Application 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
Platform
Known Vulnerabilities
Main Speaking Points:
Known vulnerabilities in web servers are obviously a source of great risk.
However it is the most easily defended against. You install a patch.
The difficulty becomes installing patches on lots of server
You must have streamlined patching procedures
You must be able to easily inventory your servers for patches
Don’t worry, if you miss a patch, a hacker will let you know

53. Web Application Vulnerabilities
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
Administration
Extension Checking
Common File Checks
Data Extension Checking
Backup Checking
Directory Enumeration
Path Truncation
Hidden Web Paths
Forceful Browsing
Main Speaking Points:
-Administrative issues are less easily corrected than known issues.
-Require a security awareness from those who manage the website and it’s content on a daily basis
Obviously you don’t want directory browsing enabled anywhere, and you want the right ACL’s
More than just configuration – must be aware of the implication of content as well
For example: remnant files like readme.txt’s or sample applications can reveal the applications and versions in use.
Commercial applications has known vulnerabilities too, not just webservers and operating systems.
Backup files or improper application mapping can reveal source code, including the information necessary to connect to the database

54. Web Application Vulnerabilities
Application Programming:
Common coding techniques do not necessarily include security
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
Application
Administration
Administration
Application Mapping
Cookie Manipulation
Custom Application Scripting
Parameter Manipulation
Reverse Directory Transversal
Brute Force
Cookie Poisoning/Theft
Buffer Overflow
SQL Injection
Cross-site scripting
Main Speaking Points:
The application logic itself must be careful constructed and must include security mechanisms
Don’t assume that the input you received is what you expected. It must be tested, validated, and filtered. Test before you ingest
Be extremely careful how you call up files, especially if you pull files directly from the file system. You could expose your pages’ source code, or worse yet, expose system files.
Be particularly careful to remove anything that even resembles javascript or vbscript. Inadvertently storing scripts entered from a hacker will allow them to be replayed against your customers, resulting in your website attacking your customers or divulging session information to the hacker.
Handle all error messages. Unhandled (raw) error messages are a roadmap through the application and database.
Structure your database calls carefully, and scrutinize any user-input that will become used in the query. Carefully constructed input could allow a hacker to piggy-back your queries with their own, letting them access the database through the web application.

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…

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
Where to begin?

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
Where to begin?

58. Questions/Comments?