Description of "Web Application Architecture" Web Application Technologies Scenario : " Tampering HTTP Requests " Introducing HTTP Protocol HTTP Requests and Responses HTTP Methods URLs HTTP Headers Cookies HTTP Proxies Web Functionality Server-Side Functionality Client-Side Functionality 4 HTTP Security headers Content-Security-Policy X-Frame-Options X-Content-Type-Options Strict-Transport-Security

1. Web Application Security (PHP)
Zakieh Alizadeh
zakiehalizadeh@gmail.com
APALaboratory – FerdowsiUniversity of Mashhad

2. Session 1
Web Application Architecture

3. Web Application Architecture
q Table of Content
§ Description of "Web Application Architecture"
§ Web Application Technologies
§ Scenario : " Tampering HTTP Requests "
o Introducing HTTP Protocol
• HTTP Requests and Responses
• HTTP Methods
• URLs
• HTTP Headers
• Cookies
• HTTP Proxies
o Web Functionality
• Server-Side Functionality
• Client-Side Functionality

4. Web Application Architecture
oWeb Application Architecture
o HTTP
oWeb Functionality
• Server-Side Functionality
• Client-Side Functionality

5. Web Application Architecture
q Web Application Architecture
§ Web applications are computer programs allowing website visitors to submit and retrieve
data to/from a database over the Internet using their preferred web browser. The data is
then presented to the user within their browser as information is generated dynamically (in
a specific format, e.g. in HTML using CSS) by the web application through a web server.
§ Web browsers are software applications that allow users to retrieve data and interact with
content located on web pages within a website

6. Web Application Architecture
qWeb Application Architecture
§ How to server and client communicate?
HTTP
Protcol

7. Web Application Architecture
q Web Application Architecture
1. A person types in the URL of the internet website that he/she wants to visit:
o http://www.cert.um.ac.ir/login.php?username=test&&pass=123456
2. The client browser then splits the URL to three separate parts:
o the protocol (in this example it’s “http”),
o the server address/server name (in this case www.cert.um.ac.ir)
o part of the URL (i.e.thefile name) which you requested for (in this case it’s “login.php”).
3. The next step for the browser is to send a special “GET” request to the web server in
order to retrieve the address and the page it has been provided.
4. The browser will translate all the data into the HTML format and render the result to the
user on his/her screen.

8. Web Application Architecture
qWeb Application Architecture
Login.php
Code:
If ($user==ali && pass==123456)
Username password
see
Response
DB
Server
http://www.cert.um.ac.ir/login.php? username=test&&pass=123456

9. Web Application Architecture
oWeb Application Architecture
o HTTP
oWeb Functionality
• Server-Side Functionality
• Client-Side Functionality

10. HTTP
qHTTP
§ HTTP is Client-Server Protocole. Http uses a message-based model in
which a client sends a request message,and the server returns a response
message.

11. HTTP
qWeb Application Architecture
§ HTTP

12. HTTP
q HTTP History
§ HTTP v0.9 : The first documented version of HTTP was HTTP V0.9 (1991). The first version of the protocol
had only one method, namely GET, which would request a page from a server
o Request Methode :Get
§ HTTP/1.0: RFC 1945 officially introduced and recognized HTTP V1.0 in 1996.
o Request Methode s: GET, POST and HEAD
§ HTTP /1.1 : The HTTP/1.1 standard as defined in RFC 2068 was officially released in January 1997
o Request Methode s: GET, POST ,HEAD, HTTP/1.1 added 5 new methods: OPTIONS, PUT, DELETE, TRACE and
CONNECT
q Http Messages
§ Http request message
§ Http response message

13. HTTP
qHTTP Requests
§ All HTTP messages (requests and responses) consist of one or more headers
,each on a separate line, followed by a mandatory blank line, followed by an
optional message body. A typical HTTP request is as follows:

14. HTTP
qHTTP Requests

15. HTTP
qHTTP Headers
§ All HTTP messages (requests and responses) consist of one or more
headers ,each on a separate line, followed by a mandatory blank line,
followed by an optional message body.

16. HTTP
qHTTP Headers

17. HTTP
qHTTP Requests
§ All HTTP messages (requests and responses) consist of one or more headers
,each on a separate line, followed by a mandatory blank line, followed by an
optional message body. A typical HTTP request is as follows:

18. HTTP
qHTTP Request Methods
§ HTTP defines methods to indicate the desired action to be performed on
the identified resource.

19. HTTP
qHTTP Request Methods
§ HTTP defines methods to indicate the desired action to be performed on
the identified resource.

20. HTTP
q HTTP Response
§ The response message consists of the following:
o A Status-Line (for example HTTP/1.1 200 OK)
o Response Headers, such as Content-Type: text/html
o An empty line
o An optional message body

21. HTTP
qHTTP Status Code
§ Each HTTP response message must contain a status code in its first line,
indicating the result of the request. The status codes fall into five groups,
according to the first digit of the code:
Code Desc Example
1xx Informational. 101 : Switching Protocols
2xx The request was successful. 200 : OK
3xx The client is redirected to a different resource. 300 : Multiple Choices
4xx The request contains an error of some kind. 400:Bad Request
5xx The server encountered an error fulfilling the request. 503 Service Unavailable

22. HTTP
qURL
§ A uniform resource locator (URL) is a unique identifier for a web
resource, via which that resource can be retrieved.
protocol://hostname[:port]/[path/]file[?param=value]
http://cert.um.ac.ir/login.php? user=Ali && pass=123456
hostname parameterspath

23. HTTP
qURL
Login.php
Code:
If ($user==ali && pass==123456)
Username password
see
Response
DB
Server
http://cert.um.ac.ir/login.php? user=Ali && pass=123456
hostname parameterspath

24. HTTP
q Cookies
§ The cookie mechanism enables the server to send items of data to the client, which
the client stores and resubmits back to the server. Unlike the other types of request
parameters (those within the URL query string or the message body), cookies continue
to be resubmitted in each subsequent request without any particular action required
by the application or the user.
§ A server issues a cookie using the Set-Cookie response header, as already observed:
Set-Cookie : theme=black
header value

25. HTTP
qHTTPS
§ The The HTTP protocol uses plain TCP as its transport mechanism, which is
unencrypted and so can be intercepted by an attacker who is suitably
positioned on the network.
§ HTTPS is essentially the same application-layer protocol as HTTP, but this is
tunneled over the secure transport mechanism, Secure Sockets Layer (SSL).

26. HTTP
qProxy Server
§ In computer networks, a proxy server is a server (a computer system or an
application) that acts as an intermediary for requests from clients seeking
resources from other servers.
§ A server that sits between a client application, such as a Web browser, and a
real server. It intercepts all requests to the real server to see if it can fulfill the
requests itself. If not, it forwards the request to the real server.

27. HTTP
qType of Proxy Server
ü Http proxy Servser
ü A one way request retrive web app.
§ FTP proxy Servser
§ SSL proxy Servser
§ Socks Proxy Server
§ NAT Proxy Server
§ Caching Proxy Server
§ Web Proxy Server

28. HTTP
qHTTP Proxies
§ An HTTP proxy server is a server that mediates access between the client
browser and the destination web server.
§ When a browser has been configured to use a proxy server, it makes all of
its requests to that server, and the proxy relays the requests to the
relevant web servers, and forwards their responses back to the browser.

29. HTTP
qHTTP Proxies
§ When doing a manual security assessment of a web application you
generally only require a web browser and a local proxy server that allows
you to trap and modify requests. Some proxies:
ü Tamper Data
o Burp Proxy
o Owasp Web Scarab
Other..

30. HTTP
q HTTP Proxies
ü Tamper Data
ü Use tamperdata to view and modify HTTP/HTTPS headers and post parameters. Trace and time http
response/requests. Security test web applications by modifying POST parameters.
§ Burp Proxy
o Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications. It
operates as a man-in-the-middle between the end browser and the target web server, and allows
the user to intercept, inspect and modify the raw traffic passing in both directions.
§ Owasp Web Scarab
o WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS
protocols. It is written in Java, and is thus portable to many platforms.

31. Web Application Architecture
oWeb Application Architecture
o HTTP
oWeb Functionality
• Server-Side Functionality
• Client-Side Functionality

32. Web Functionality
q Web Functionality
§ Client side is the user;s end of the experience, while server side is based on the
server's end. As a developer
o Server-Side Functionality
o Client-Side Functionality

33. Web Functionality
qServer-Side Functionality
§ Server side, however, you decide which platforms, operating systems,
programming languages, frameworks, and libraries will be used. a wide
range of technologies on the server side to deliver their functionality:
• Scripting languages such as PHP, VBScript, and Perl
• Web application platforms such as ASP.NET and Java.
• Web servers such as Apache, IIS, and Netscape Enterprise
• Databases such as MS-SQL, Oracle, and MySQL.
• Other back-end components such as file systems, SOAP-based web services,and
directory services.

34. Web Functionality
q Client-Side Functionality
§ In order for the server-side application to receive user input and actions, and present the
results of these back to the user, it needs to provide a client-side.
§ Client side Scripting is possible to be blocked , where as server side scripting can't be
blocked by the user , so if you validate using CLIENT SIDE only , and client side scripting
blocked then even validation can not be done and directly even wrong data can be accepted
and thus makes a flaw in the system.
o HTML
o Hyperlinks
o Forms
o JavaScript
o Java applets
o ActiveX controls

35. Web Functionality
qIntroducing Some Security Testing Firefox Extensions
§ Cookieh manager.
§ tamperdata

36. Web Functionality
qScenario : " Tampering HTTPRequests “
§ Instal l tmper data add ons in firefox
§ Change username sent to web app

37. Web Functionality
qSetting Headers in php

38. Web Functionality
q4 HTTP Security headers
§ Content-Security-Policy
§ X-Frame-Options
§ X-Content-Type-Options
§ Strict-Transport-Security

39. Web Functionality
qContent-Security-Policy
§ Adding the Content-Security-Policy header with the appropriate value allows
you to restrict the origin of the following:
o script-src: JavaScript code (biggest reason to use this header)
o connect-src: XMLHttpRequest, WebSockets, and EventSource.
o font-src: fonts
o frame-src: frame ulrs
o img-src: images
o media-src: audio & video
o object-src: Flash (and other plugins)
o style-src: CSS

40. Web Functionality
qContent-Security-Policy
Content-Security-Policy: script-src 'self' https://apis.google.com
Content-Security-Policy-Report-Only: script-src 'self';
report-uri /csp-report-endpoint/
Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element.

41. Web Functionality
qContent-Security-Policy

42. Web Functionality
qContent-Security-Policy

43. Web Functionality
qContent-Security-Policy
§ Enforcing multiple policies.
Content-Security-Policy: default-src 'self' http://example.com http://example.net;
connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
script-src http://example.com

44. Web Functionality
qWhere does it work?

45. Web Functionality
qX-Frame-Options
§ This will cause browsers to refuse requests for framing in that page.
§ 'SAMEORIGIN' will allow framing only from the same origin
§ 'ALLOW FROM http://url-here.example.com' will allow you to specify an
origin (unsupported by IE).
X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN
X-Frame-Options: ALLOW FROM http://url-here.example.com

46. Web Functionality
q X-Content-Type-Options
§ This isn't made any easier by browsers second-guessing the Content-Type of what
you're serving by doing Mime Sniffing.
§ The X-Content-Type-Options allows you to, in effect, say to browsers that yes, you
know what you're doing, the Content-Type is correct with it's only allowed
value: 'nosniff'.
§ This reduces exposure to drive-by download attacks
X-Content-Type-Options: nosniff

47. Web Functionality
qX-Content-Type-Options

48. Web Functionality
qStrict-Transport-Security
§ Then even typing in http://hsts.example.com will make the browser connect
to https://hsts.example.com.
§ It will do this for as long as the HSTS header is valid, which in the case of the
example is 1 year since the last response that sent the HSTS header. So if I
visit the site once on January 1st 2013, it will be valid until January 1st 2014.
Strict-Transport-Security: max-age=31536000; includeSubDomains

49. Web Functionality
qStrict-Transport-Security

50. Web Functionality
qHSTS mechanism overview
§ A server implements an HSTS policy by supplying a header over an
HTTPS connection (HSTS headers over HTTP are ignored).
§ For example, a server could send a header such that future requests to
the domain for the next year (max-age is specified in seconds, 31536000
is approximately one year) use only HTTPS: Strict-Transport-Security:
max-age=31536000

51. Web Functionality
qHSTS mechanism overview
§ . When a web application issues HSTS Policy to user agents, conformant
user agents behave as follows:
1. Automatically turn any insecure links referencing the web application into
secure links. (For instance, http://example.com/some/page/ will be
modified to https://example.com/some/page/ before accessing the server.)
2. If the security of the connection cannot be ensured (e.g. the server's TLS
certificate is not trusted), show an error message and do not allow the user
to access the web application.[15]

52. Web Functionality
qFacebook
§ As of January 2013 Facebook main page was setting these security
related HTTP headers.

53. Web Functionality
qFacebook
§ As of July 2014, the following headers were set:

54. Web Application Architecture