LIST
cdk commands cdk init app --language typescript cdk synth # create cloudformation files cdk bootstrap # create stack in cloudformation cdk deploy # synth + deploy cdk deploy [<stack-name>] cdk deploy --all cdk list cdk diff # cf terraform plan cdk destroy <stack-name> # cf terraform down https://docs.aws.amazon.com/cdk/api/v2/docs/aws-construct-library.html
result.body = error.message compile error, because the type of the object ’error’ is unknown result.body = (error as AWSError).message force casting hides the error, but gives no guarantee that message actually exists! there is no guarantee that error is of type AWSError and actually has that field! And non of the ‘as’ casting remains at runtime So it will just act like message = ‘undefined’ if it is not there...
type information is only available at compile time, not at runtime Type guards are ways to check at runtime if an object matches. use of keywords typeof instanceof in instanceof if(x instanceof SomeObjectConstructor) typeof if(typeof a === 'string') typeof only works with “string” | “number” | “bigint” | “boolean” | “symbol” | “undefined” | “object” | “function” in if('firstName' in obj) checks if attribute exists (src: TypeScript Type Guards, AWS & Typescript Masterclass - Typescript recap)
(Why your daily stand-ups don’t work and how to fix them) Model: 5 heuristics you’re doing stand-ups wrong symptoms which indicate you’re doing your stand-ups in the wrong way, for the wrong reasons: Heuristic: Stand-ups take more than 15-minutes Heuristic: People talk about their work instead of talking about goals Heuristic: People stop showing up regularly Heuristic: People talk to their manager (or “scrum master”) instead of talking to their peers Heuristic: If the manager or “scrum master” can’t show up, the stand-up doesn’t happen Quote: the purpose of daily stand-ups the purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work....
OWASP top 10 Open Web Application Security Project https://owasp.org/ OWASP top 10 - 2013 (Book_ release it!) Injection Broken Authentication and Session Management Cross Site Scripting (XSS) Broken Access Control Security Misconfiguration Sensitive Data Exposure Insufficient Attack Protection Cross-Site Request Forgery (CSRF) Using Components with Known Vulnerabilities Underprotected APIs (src: Book_ release it! - Michael Nygard) 2017 added (4) XML External Entities (XXE) covered in (2013.1) OWASP Injection by [[book-release-it-michael-nygard.md|Book_ release it!...
Broken Access Control application problems that allow attackers to access data they shouldn't eg. other user’s data eg. system data like passwords file a) direct object access url probing anti-pattern: database IDs in URLs pattern: unique non-sequential IDs pattern: generic URL that is session sensitive (eg. /users/me) pattern: session-specific mapping from random IDs to real IDs 😞 service must populate all response URLs 😞 links will not persist across sessions (violates REST) authorize access to objects...
session session hijacking anti-pattern: session id in plain text ref: cross site scripting (XSS) session fixation (hacker creates valid session, and tries to get the target to use it) Anti-pattern: authenticating an existing session pattern: generate a new session ID when (re)authenticating session prediction Anti-pattern: session IDs based on user’s own data Anti-pattern: sequential session ids just because a session looks random, does not mean it is random guidelines for handling session IDs !...
a) server-side rendering // Don't do this String queryBox = "<input type='text' value ='" + request.getParameters("search") + "' />"; b) front-end apps 😞 put content straight into DOM without escaping c) admin / customer-service GUIs eg. contact form form submitted with hostile data admin pulls up the record executes on admin’s browser eg. log viewers put hostile data in log string admin uses web log viewer executes on admin’s browser solution...
Cross-Site Request Forgery (CSRF) pattern: use anti-CSRF tokens for requests with side-effects eg. password changes, address changes, purchases pattern: SameSite cookie policy Set-Cookie: SID=...; SameSite=strict 😞not zero-cost -> requires changes in session management approach session “read” cookie: not same-site (GET requests) session “write” cookie: same-site strict (state changing requests) ref: Cross-Site Request Forgery Prevention - OWASP Cheat Sheet (src: Model_ OWASP top 10 Book_ release it! - Michael Nygard)
Injection in general, if a service builds queries by bashing strings together and any of those strings come from a user, that service is vulnerable. A) database (SQL) injection “comes from a user” data from a database may have originated from a user as well B) XML injection OWASP XML External Entities (XXE) (src: Book_ release it! - Michael Nygard)