Web Development Cheat Sheet by SalJose24

Modes of attacks on web applic­ations
● Attack the connection between browser and web server
○ Steal password
○ Hijack existing connection
● Attack the server
○ Inject code that does bad things
● Attack the browser
○ Inject code that does bad things
● Breach the browser, attack the client machine
● Fool the user (phishing)

Security Defenses
● Isolation in browsers
○ Web app run in isolated sandbox
● Crypto­graphy

Same-O­rigin Policy
● General idea: separate content with different trust levels into different frames, restrict commun­ication between frames
● One frame can access content in another frame only if they both came from the same origin
● Origin is
○ Protocol
○ Domain name ○ Port
● Access applies to DOM resource, cookies, XMLHtt­pRe­que­st/AJAX requests
● Doesn't apply: <sc­rip­t> tags
○ Javascript executes with full privileges of the enclosing frame.

○ Protect inform­ation from unauth­orized viewing
○ Detect changes
○ Determine origin of inform­ation
● Web develo­pment frameworks
○ Use patterns that help, avoid dangerous ones

same-o­rigin policy is too restri­ctive
● There are times when it is useful for frames with different origins to
commun­icate
○ Example: Sub-do­mains of same organi­zation
○ Web fonts
○ Content distri­bution network
HTML5 feature: Access­-Co­ntr­ol-­All­ow-­Origin
● Access­-Co­ntr­ol-­All­ow-­Origin header in HTTP response:
Access­-Co­ntr­ol-­All­ow-­Origin: http:/­/fo­o.com
Access­-Co­ntr­ol-­All­ow-­Met­hods: PUT, DELETE
HTML5 postMe­ssage - safe messaging
● Sender (from domain a.com) to an embedded frame of different domain

Angular criticisms
Digest cycle overheads on pages with large numbers of items,­Con­sider the watches on a large data table with multiple column­s,HTML template with two-way bindin­g,DOM access overhe­ad,­Access to the browser DOM is slow,Large size of JavaSc­rip­t,Needs to download, initia­lize, and digest before anything appear­s,P­rob­lematic on mobile, Software engine­ering problems progra­mming at scale, Scope inheri­tance, JavaScript lack of typing, interface defini­tions,
Node
Callback hell - TJ Holowa­ychuk's why Node sucks:
1. you may get duplicate callbacks
2. you may not get a callback at all (lost in limbo)
3. you may get out-of­-band errors
4. emitters may get multiple “error” events
5. missing “error” events sends everything to hell
6. often unsure what requires “error” handlers
7. “error” handlers are very verbose
8. callbacks suck
JavaScript lack of typing checking Concur­rency support (e.g. crypto operat­ions)
Mongo
Lots - Pretty lame database
○ Loses data, doesn't scale well
○ Large space overheads for objects and indexes
○ Query language
○ Limited concur­rency control (only single object transa­ctions)
○ Not SQL?

^{"man in the middle­" attacks
● Attacker has access to network commun­ication between browser and server.
● Passive attacks:
○ Eavesdrop on network traffic
● Active attacks:
○ Inject network packets
○ Modify packets
○ Reorder, replay packets
○ Block packets
Certif­icate authority: well-k­nown, trusted server that certifies public keys. Certif­icate: a document encrypted with the secret key of a certif­icate authority
○ Identifies a particular service along with its public key
Certif­icate author­ities establish selfs as well known services on Internet
○ Browsers hard-wired to accept certif­icates from dozens of author­ities
● Internet services compute keys, gives the public key to a certif­icate authority along with proof of identity
● Certif­icate authority returns a certif­icate for that service.
● Service can pass along this certif­icate to browsers
○ Browser can validate the certif­icate came from the certif­ication authority and see who the certif­ication authority thinks the browser is talking to.
● Trust: Browser trusts to certif­ication authority
Secure Sockets Layer (SSL) & Transport Layer Security (TLS) - HTTPS
● Protocol used for secure commun­ication between browsers and servers
Excuses for not using HTTPS for all Web traffic?
● Expensive: slows down Web servers
● Breaks web page caching
Problem: SSL
When server returns pages with HTTPS links, attacker changes them to HTTP.
● When browser follows those links, attacker intercepts requests, creates its
own HTTPS connection to server, and forwards requests via that
Problem: Mixed content
● Main page loaded with HTTPS, but some internal content loaded via HTTP (e.
g. <script src="ht­tp:­//.../­scr­ipt.js­"­>). ○ Network attacker can modify content to attack page.}

get user's session id - session ids must be unpred­ictable use framework
Use Https to protect cookies - change session id after logging in
Cross Site Forgery Request (CSFR)
visiting multiple pages (attac­ker's website) - mark pages, Don't accept POST submission directly from forms, HTTP GET should not have side effects, have JavaScript include special HTTP request header property with secret
Data Tampering
Message Authen­tic­ation Codes (MAC) - MAC function takes arbitr­ary­-length text, secret key, produces a MAC that provides a unique signature for the text, Server includes MAC with data sent to the browser, Browser must return both MAC and data, check for tampering
need: Authen­tic­ation - Know that we (the web server) authored the inform­ation Integrity - Known that it wasn't tampered with, Need encryption if we want confid­ent­iality

What happens if someone inputs a comment with a script tag?
<script src="ht­tp:­//w­ww.e­vi­l.c­om/­dam­age.js­" />, Called a Cross Site Scripting Attack (XSS)
Stored Cross Site Scripting Attack
● Attacker stores attacking code in a victim Web server, where it gets accessed by victim clients
Reflected Cross Site Scripting
● Attacker doesn't need to store attack on website, can just reflect it of the website
Modern JavaScript frameworks have better defences
● Angular bind-html - Sanitizes HTML to remove script, etc.
SQL Injection - Don't write SQL

Fool people to disclose personal info
Problem: too easy to obtain certif­icates
Counte­r-m­easure: extended validation certif­icates - vet the organi­zation, warn users
Spear phishing - Phishing with attacker having personal inform­ation

An attack that causes a service to fail by using up resources
None perfect - really hard problem
Do want to take steps to avoid accidental DOS and make purpos­e-d­riven DOS harder, Resource quotas, Track resource consum­ption per user and provide way of cutting off users, Good for catching accidents, less so for malicious attacks, Make resources cost money, Raises the cost or hassle for an attacker, Not always possible under business model, Network layer: Need to push back on attack stream

scale-out archit­ecture - make more instances, Benefits of scale-out
Can scale to fit needs: Just add or remove instances
Natural redundancy make tolerating failures easier: One instance dies others keep working
DNS (Domain Name System) load balancing:
○ Specify multiple targets for a given name
○ Handles geogra­phi­cally distri­buted system
○ DNS servers rotate among those targets
Load-b­ala­ncing switch ("Layer 4-7 Switch­")
● Special load balancer network switch
○ Incoming packets pass through load balancer switch between Internet and web servers
○ Load balancer directs TCP connection request to one of the many web servers
○ Load balancer will send all packets for that connection to the same server.
Data sharding - Spread database over scale-out instances
○ Each piece is called data shard
○ Can tolerate failures by replic­ation - place more than one copy of data (3 is common)
Memcache: main-m­emory caching system
Many useful services available:
○ Auto scaling (spinning up and down instances on load changes)
○ Geographic distri­bution (can have parts of the backend in different parts of the world)
○ Monitoring and reporting (what parts of web app is being used, etc.)
○ Fault handling (monit­oring and mapping out failed services
Content Distri­bution Network (CDN)
● Consider a read-only part of our web app (e.g. image, html template, etc.)