CS 322 FInal

REST Principle #1

The key abstraction of information is a resource, named by a URI. Any information that can be named can be a resource

REST Principle #3

The representation of a resource is a sequence of bytes, plus representation metadata to describe those bytes. The particular form of the representation can be negotiated between REST components

What is a URI?

Uniform Resource Identifier (URI) is an 'address' of a resource • A resource must have at least one URI • No URI -> Not a resource

Security Requirements for Mantaining States

In case of necessity: use of strong (pseudo-) random numbers Sufficient session ID randomness Sufficient session ID length • Servers should be able to terminate sessions in case of necessity (independent from client session token validity) • Session time-out after a certain amount of time • Use different session identifiers when shifting between secure and insecure contents (i.e. http vs. https, sensitive application areas vs. nonsensitive, etc.) • Limited trust delegation • Asking for re-authentication prior to sensitive actions • Prevention of unauthorized manipulation of session data • Prevention of theft of sensitive session tokens and user credentials • Prevention/detection of brute force attacks and/or password guessing

Is DELETE Idempotent and safe?

Its idempotent and NOT safe

Is PUT Idempotent and safe?

Its idempotent and NOT safe

Why Docker Compose?

Make your development environments: • Repeatable • Isolated • Fast

Is %100 RESTful architecture valuable?

No, 100% RESTful architecture is not practical and not valuable either • Need to be unRESTful at times (Eg.: Login/Logout)

Are Sessions RESTful?

No, Sessions are NOT RESTful (i.e. sessions = state)

Is POST Idempotent and safe?

No, it is neither idempotent or safe

Delegating authorization to a third-party is called: (A)OAuth (B)Trust delegation (C)Token-based authentication (D)All of the above

(A)OAuth

Session protection is used to (A) Fight against attacks from cookies being stolen (B) Fight against attacks from session being stolen (C) Fight against attacks from session variables and cookies being stolen (D) Fight against attacks from session variables, cookies, and configurations being stolen

(B) Fight against attacks from session being stolen

Which is not a property of a good "hash"? (A) Looks random (B) Easy to tell if Hash(key) is valid or invalid (C) Easy to predict key from the hash (D) Very deterministic for the computer

(C) Easy to predict key from the hash

The most secure way to retrieve a lost password is (A) Send an email to the administrator (B) Retrieve the clear-text password from the password database (C) Reset the password (D) Use tokens

(C) Reset the password

RESTful APIs

REST (REpresentational State Transfer) • A web architectural style of the web • REST is a set of design criteriaand not a physical structure • REST is not tied to the Web i.e. doesn't depend on the mechanics of HTTP

Steps to a RESTful Architecture

1. Figure out the data set 2. Split the data set into resources 3. For each kind of resource name resources with URIs 4. Expose a subset of uniform interface 5.Design representation(s) accepted from client (Form-data, JSON, XML to be sent to server) 6. Design representation(s) served to client (file-format, language and/or (which) status message to be sent) 7. Consider typical course of events: sunny-day scenarios 8. Consider alternative/error conditions: rainy-day scenarios

Authentication and authorization: four ways

1. Password based • We SHOULD use a hash function! 2. Token based: Send credentials first; get a token with an expiration time. Use token for subsequent transactions (sending credentials again and again is not a good idea!) 3. OAuth: Similar to token-based authentication Use third party services (e.g., from Google, Facebook) 4. Key exchange

REST Principle #2

All interactions are context-free: each interaction contains all of the information necessary to understand the request, independent of any requests that may have preceded it.

How to change Cookies or Hidden Fields

Changing cookies, URLs or hidden fields is quite simple All you need is (one of) the following: • Local proxy (e.g. Paros) • Text editor, for persistent cookies stored in text files • Telnet or other simple Unix tools • In case of URLs you need no editor at all... • Sometimes: Base64 decoder

REST Principle #4

Components perform only a small set of well-defined methods on a resource producing a representation to capture the current or intended state of that resource and transfer that representation between components. These methods are global to the specific architectural instantiation of REST; for instance, all resources exposed via HTTP are expected to support each operation identically

Token based

Sometimes you want to send some data to untrusted environments, then get it back later. To do this safely, the data must be signed to detect changes. Given a key only you know, you can cryptographically sign your data and hand it over to someone else. When you get the data back you can ensure that nobody tampered with it. The receiver can see the data, but they can not modify it unless they also have your key. So if you keep the key secret and complex, you will be fine.

Authenticate, Authorize, Access

Step 1: Authenticate with username, password, key Prove you are "who you say you are" Step 2: Get authorization to access resource (e.g., calendar data) Permission to access resource Step 3: Get the resource itself (e.g. using REST APIs)

Is GET Idempotent and safe?

yes

Is HEAD Idempotent and safe?

yes

Cryptographic hashes

• A Cryptographic Hash Function is an algorithm that maps data (message) of arbitrary size to a fixed-size array (digest). • Must be: • Deterministic • Practically infeasible to reverse • Quick to compute • One-to-one (no two different messages can have the same digest) • Avalanche effect: small change to messages should generate a new digest that is uncorrelated to the original.

Database Management System (DBMS)

• A collection of files that store the data. • A program written by someone else that accesses and updates the data for you.

Idempotence

• A method is idempotent if it can be called many times without different outcomes. It would not matter if the method is called only once, or ten times over. The result should be the same. Again, this only applies to the result, not the resource itself. • Some idempotent operations have an additional, special property: safety.

RESTful API: Resource

• A resource is anything that's important enough to be referenced as a thing in itself • Something that can be stored on a computer and represented as a stream of bits: • A document (e.g. information about COVID-19) • Row in a DB (e.g. 'User Profile')

Maintaing States: URL-based Solution Problems

• All information contained in the URL might be stored in firewall or proxy log files • Also, it could simply be printed out with the web page on a shared printer • Moreover, the URL, including potentially sensitive data, can be sent in the HTTP referrer field to other web servers. This implies a high risk of sensitive session data being disclosed to unauthorized third parties

RESTful Frameworks

• Almost all frameworks allow you to: 1. Specify URI Patterns for routing HTTP requests 2. Set allowable HTTP Methods on resources 3. Return various different representations (JSON, XML, HTML most popular) 4. Support content negotiation 5. Implement/follow the studied REST principles

RESTful API: Addressability

• An application is addressable if it exposes interesting aspects of its data set as resources • An addressable application exposes a URI for every piece of information it might conceivably serve (usually infinitely many) • Most importantly from end-user perspective • Addressability allows one to bookmark URIs or embed them in presentations/books

Where are Database Management System (DBMS) used?

• Backend for traditional "database" applications • Backend for large websites • Backend for web services

Functionality of Docker Compose

• Building images (if an appropriate Dockerfile is provided) • docker-compose build • Healing, i.e., re-running containers that have stopped • docker-compose up --no-recreate

docker-compose up

• Builds images from Dockerfiles (if needed) • Pulls images from registries • Creates and starts containers • Streams their logs

Security properties of an information system

• Confidentiality: Don't leak confidential information about users • Integrity: Don't allow unauthorized changes to information • Availability: Information and service is available when needed

Usual solutions for Mantaining States

• Cookies • Forms with hidden fields (<input type="hidden" /> ) • HTTP headers such as: Referer, Authorization (Basic/Digest Authentication) • Client Certificates

Maintaing States: Cookie-based Solutions

• Cookies are a simple session management mechanism • Cookies have been designed to track status information about user visits on web servers (who requested which pages at what time) • Originally, nobody intended to use cookies for authentication purposes • Nevertheless, a large quantity of web applications today uses cookies for user authentication and authorization • Cookies are normally sent from the web server to the client using two different methods: either within HTTP headers or by JavaScript

What is Docker Compose?

• Docker Compose is a tool for defining, running, and managing complex multi-container Systems

What is Docker?

• Docker allows the application to be packaged up and deployed with all of the parts it needs (libraries, other dependencies, etc.). It provides a certain amount of OS independence

Maintaining States: Form-based Solutions with Hidden Fields Problems

• Does not provide pre-defined protection mechanisms as those provided by cookies (for example, secure socket layer) • Requires repeated sending of HTTP forms via POST commands, which implies a certain amount of overhead that might reduce performance. • Note: Hidden fields cannot last beyond a certain interactive session

Maintaing States: Active and Passive Attack Scenarios

• Eavesdropping • Session Fixation* • Cross-Site Scripting (XSS)** • Exhaustive Search • Intelligent Manipulation of Session Data • Network Manipulation (e.g., change of DNS entries) •* Session Fixation is an attack that permits an attacker to hijack a valid user session. •** XSS enables attackers to inject client-side scripts into web pages viewed by other users.

RESTful API: Statelessness

• Every HTTP request happens in complete isolation • Server NEVER relies on information from prior requests • There is no specific 'ordering' of client requests (i.e. page 2 may be requested before page 1) • If the server restarts a client can resend the request and continue from it left off • Possible states of a server are also resources and should be given their own URIs!

Maintaining States: HTTP Basic and/or Digest Authentication-based Solution Problems

• HTTP Basic authentication is vulnerable to passive eavesdropping. Moreover, it provides no mechanism for explicit session expiration (i.e. logout). • HTTP Digest authentication cannot guarantee sufficient support on all client platforms. • Neither provide session tracking.

RESTful API: Uniform Interface

• HTTP provides 4 basic methods for CRUD (create, read, update, delete) operations: • GET: Retrieve representation of resource • PUT: Update/modify existing resource (or create a new resource) • POST: Create a new resource • DELETE: Delete an existing resource • HEAD: Fetch meta-data of representation only (i.e. a metadata representation) • OPTIONS: Check which HTTP methods a particular resource supports

Types of DBMSes

• Hierarchical: Tree-like structure of objects Parents have children, each node can have at most one parent. • Relational SQL Server, Oracle Databases, MySQL • Non-relational (NoSQL) MongoDB

Maintaining States: Stronger Improvements: Dynamic Links

• Idea: generate dynamic links that include session identifier information (e.g. user ID and previous page) • Different implementation variants are possible

Maintaining States: HTTP Basic and/or Digest Authentication-based Solutions

• In HTTP Basic authentication, the client sends username and password in clear text as part of the HTTP request • In all subsequent HTTP requests for content from subdirectories of the original request, these credentials will be automatically resent • In HTTP Digest authentication, no passwords are sent • A cryptographic hash value containing the username, password, and additional security-relevant data, will be transmitted from the client to the server

Key exchange

• Interested in having a shared secret between two sides, and the secret has to be communicated through an untrustworthy intermediary (the internet.) Generating a shared secret (i.e., encryption key) between two entities. Two entities could be - Alice and Bob - Alice and a server (e.g., hosting our scheduling app) - Two servers Encrypting traffic with that key. Even if the traffic is recorded and later analyzed, there's absolutely no way to figure out what the key was, even though the exchanges that created it may have been visible.

Docker compose Commands

• Just build, don't start: docker-compose build • docker-compose up • Use --build to force rebuilding the images: docker-compose up --build • And use --no-build to skip the image building process: docker-compose up --no-build • Stop and remove everything, including the images: docker-compose down --rmi all • Start everything in detached mode: docker-compose up -d • Run a command once in a container: docker-compose exec $SERVICE $COMMAND

Types of Schemas

• Logical • How the data is organized in tables • Physical • How the data is actually stored physically • Table names, fields, data types

Maintaining States: Conclusion

• Many web applications still suffer from weak session management • For *medium security*, a good cookie-based standard solution can be sufficient • For higher security needs, a dynamic link-based approach is recommended • Each web application should be checked against all problem categories mentioned above • Never... ever... ever... ever... trust user input!

Microservice Architecture

• Microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well- defined, lightweight mechanism to serve a business goal.

Microsoft's HttpOnly Option

• Microsoft implemented protection mechanisms into Internet Explorer 6, the so-called HTTP-only option; not part of an RFC or similar standard • *; HttpOnly* gets appended to a cookie; if IE6 receives such a cookie, it does not allow scripted access (e.g. via JavaScript) to this cookie • Other browsers may either ignore this option or even reject the whole cookie • Http-only mechanism is good, but not absolutely secure against all sorts of scripting attacks

Relational database

• Model data as a set of tables relation in the mathematical sense: A set of tuples • Clean, well-understood semantics, not tied to programming language • Transactions give clean, reliable semantics to concurrency

MongoDB: A NoSQL database

• Modeled on documents, not tables • The elements of a database are BSON structures (like JSON, but binary) • JSON = for humans (hence in AJAX) • BSON = for computers (binary encoded and specific to MongoDB) • Very limited concurrency : 'eventual consistency' • Basically, it's broken, but we live with it because it scales very well to many servers running in parallel

Benifits of NoSQL

• NoSQLs can be schema-agnostic • Allow for unstructured and semi-structured data to be processed • Can scale better to large sets of data • More popular within the open-source community • No licensing fees!

What does ORM for Mongo (MongoEngine) do?

• Object-document mapping • Define a Python object for your documents • Insert/Update/Select documents to/from your database in the form of those Objects

PUT vs. POST

• POST • Commonly used for creating subordinate resources existing in relation to some 'parent' resource • Parent: /weblogs/myweblog • Children: /weblogs/myweblog/entries/1 • Parent: Table in DB; Child: Row in Table • PUT • Usually used for modifying existing resources • May also be used for creating resources • PUT vs. POST (for creation) • PUT: Client is in charge of deciding which URI resource should have • POST: Server is in charge of deciding which URI resource should have • In practice: • PUT for updates work fine. No evidence/claim for 'why' it can't (or shouldn't) be used as such (personal preference) • POST may also be used and some purists prefer this

Persistent Cookies

• Persistent cookies will be stored (in case of Microsoft Windows2000/XP, for example) in C:\Documents and Settings\\Cookies • Each such cookie is stored in a .txt file starting with the username, followed by an "@" and some information about the issuer domain • Persistent cookies have no protection from the operating system against user manipulations

RESTful API: Representations

• Resources are NOT data - they are an abstraction of how the information/data is split up for presentation/consumption • The web server must respond to a request by sending a series of bytes in a specific file format, in a specific language - i.e. a representation of the resource

What are safe methods?

• Safe methods are methods that do not modify resources: read- only or absolutely zero side-effects. For instance, using GET or HEAD on a resource URL, should NEVER change the resource.

Why are safe methods important?

• Safe methods can be cached and prefetched without any repercussions or side effect to the resource • For example, a query to retrieve my current city doesn't change the database • Here is another example of safe method • GET /order/123 HTTP/1.1 • This will retrieve the order with ID 123. No matter how many times you execute this method, the order in the server will not be modified or impacted. That's why GET is a safe method.

Maintaing States: Popular Problems

• Secret user credentials are transmitted in the clear • Server-generated authentication data can be forged (weak crypto, exhaustive search, simple-to-guess numbering or mechanism) • Stealing of secret user credentials • No account logout

Maintaining States: Form-based Solutions with Hidden Fields

• Session token and information can be included in so-called hidden fields in a form • The form will be sent by the user client to the server with an HTTP POST command • Form-based mechanism works even in case of user client security restrictions (if, for example, no cookies are allowed). • It can also serve as a fallback mechanism.

Benefits of RESTful Design

• Simpler and intuitive design - easier navigability • Server doesn't have to worry about client timeout • Clients can easily survive a server restart (state controlled by client instead of server) • Easy distribution - since requests are independent they can be handled by different servers • Scalability: As simple as connecting more servers • Stateless applications are easier to cache - applications can decide which response to cache without worrying about 'state' of a previous request • Bookmark-able URIs/Application States • HTTP is stateless by default - developing applications around it gets above benefits

Maintaining States: Stronger Improvements: Dynamic Links Problems

• Some use JavaScript on the client side to generate those links; this allows unauthorized user manipulations • Page reload and browser *back button* can imply difficulties

MongoEngine Feilds

• StringField • FloatField • IntField • ImageField • ListField • DictField • BooleanField • DateTimeField • URLField

Which Representation to Request?

• Style 1: Distinct URI for each representation: • ex.com/press-release/2012-11.en (English) • ex.com/press-release/2012.11.fr (French) • Style 2: Content Negotiation • Expose Platonic form URI: • ex.com/press-release/2012-11 • Client sets specific HTTP request headers to signal what representations it's willing to accept • Accept: Acceptable file formats • Accept-Language: Preferred language

Cookies: The "Discard" option

• The "Discard" option tells the user client to discard the cookie as soon as the user client terminates

Cookies: The "Domain" and "Path" values

• The "Domain" and "Path" values specify the domain and corresponding folder subtree to which the cookie applies

Cookies: The "Max-Age" option

• The "Max-Age" option allows to set an explicit cookie life time. If this life time is over or if "Max-Age" is set to zero, then the cookie should be discarded by the user client. Thus, the origin server can effectively terminate a session by sending the client a corresponding Set-Cookie2 header with Max-Age=0 • If no "Max-Age" option is present, then the cookie is a so- called session cookie, i.e. the user client is supposed to store the cookie temporarily in its memory space and discard the cookie as soon as the user client terminates (i.e. the browser is closed)

Cookies: The "Port" option

• The "Port" option allows to define valid port numbers to which a given cookie can be returned. The security relevance of this feature is of minor relevance, nevertheless it could be useful in some specific scenarios

Cookies: the "Secure" Option

• The "Secure" option tells the user client that the cookie in question should be sent over an SSL-protected channel*; at least this is what common web browsers do • * SSL (Secure Sockets Layer) is a standard security protocol for establishing encrypted links between a web server and a browser in an online communication

What is the function of Docker Compose?

• The main function of Docker Compose is the creation of microservice architecture, meaning the containers and the links between them.

Maintaing States: URL-based Solutions

• The session token is part of the URL and will be transmitted to the web server through HTTP GET requests • Example: http://www.blabla.com/buy.asp?article=27781&sessionid=IE 5579901578 • This mechanism works even in case of user client security restrictions (if, for example, no cookies are allowed). Thus, it can serve as a fallback mechanism if the server detects problems with other mechanisms like cookies or JavaScript

OAuth

• The user's password is needed to authorize the user's data • It is not ok for us to collect passwords... • we might be evil, or too clumsy to protect it!

Steps for using Docker Compose

• Three steps to using Docker Compose: 1. Define each service in a Dockerfile. 2. Define the services and their relation to each other in the docker-compose.yml 3. Use docker-compose up to start the system.

What are aspects of a good URI?

• URIs should be descriptive (human parse-able) and have structure. • Bad URIs have everything as query parameters • URIs don't need to have structure/predictability but are valuable (and easier) for the (human) clients to navigate through the application • May have multiple URIs to refer to the same resource - convenient but confusing • Each URI must refer a unique resource - although they may point to the 'same one' at some point in time (Ex.: .../latest.tar.gz and .../v1.5.6.tar.gz)

Ad Hoc Measures / Recommendations

• Use session identifier strings that cannot be efficiently guessed or otherwise computed • Use long (pseudo) random numbers within session identifiers • Do not store session status information in cookies and/or URL strings or hidden fields • Use a session identifier on the client side that refers to only relevant information that is stored on the server side • In case that session information must be stored on the client side, then it should be encrypted and/or cryptographically hashed • Change session identifiers whenever the user switches between authenticated/unauthenticated, secure/insecure areas, etc. • Make use of cookie security options (as described above) • Use a combination of URL-/Cookie-/Hidden Field-based session identifiers (each using a different ID string) • Make use of the HTTP referrer field as an additional security feature: deny requests with wrong referrer data • Divide the application into two parts on separate servers: one for "insecure" HTTP requests, the other for "secure" HTTPS requests; include corresponding path restrictions in the cookie path option

Where would we need a "state"?

• User authentication management • User preferences management • Site history of previously seen contents • Authorization and status information (e.g. "valid customer", "shopping cart items", etc.) • Trust delegation within (distributed) web applications

Schema advantages

• Validation • Prevents invalid documents from being even inserted into a collection. • Provides consistency. • MongoDB supports schema validation since v3.2. • Object-relational mapping (Object-Document mapping)

Problems with not using DBMS

• there may be system crashes • Can't be simultaneously accessed by many users

Why use a Database?

• to factor out variable parts in the code • Values change often • lasts longer than a session • can hold more data and often • to hold data shared by more than one user

Are Cookies RESTful?

Yes, Cookies, if used appropriately (for storing client state) are RESTful

A transaction, in the context of a database

a logical unit of operation that is independently executed for data retrieval or updates.