Speaker 1: Welcome back to the deep dive. Today. We're really getting
Speaker 1: into some source material you shared with us. It's excerpts
Speaker 1: from Advanced ASP dot net Core three security.
Speaker 2: That's right, and our mission really is to unpack this,
Speaker 2: pull out the key stuff you need to know about
Speaker 2: web app security, especially in that ASP dot net core
Speaker 2: three context.
Speaker 1: Yeah, think of it as a focused tour. We want
Speaker 1: to get you the crucial concepts, common attacks, practical defenses,
Speaker 1: all straight from this material exactly.
Speaker 2: We're aiming for those moments where it clicks, maybe some
Speaker 2: surprising bits along the way that really stick.
Speaker 1: We'll cover quite a bit starting with the basics what
Speaker 1: is security online? Then look at how attacks happen, common
Speaker 1: ones like SEQL injection.
Speaker 2: EXSS, and specifically how aspnt core three deals with them.
Speaker 2: Sometimes the default behavior is well interesting. We'll definitely cover authentication, authorization, testing,
Speaker 2: a whole life cycle.
Speaker 1: Really, the goal isn't just a list, right, it's the
Speaker 1: why why these things matter, so you can build systems
Speaker 1: that are genuinely solid.
Speaker 2: Absolutely, it's about context, not just checklists.
Speaker 1: Okay, so let's kick things off right at the beginning.
Speaker 1: Security for websites applications. What are we actually trying to
Speaker 1: protect the source brings up the classic model, the CIA triad.
Speaker 2: Ah yes, CIA good old confidentiality, integrity and availability.
Speaker 3: Simple concepts, but.
Speaker 1: Fundamental confidentiality first, keeping things secret.
Speaker 2: Pretty much Yeah, making sure only the right people or
Speaker 2: systems can access sensitive data, you know, like customer info,
Speaker 2: private messages.
Speaker 1: That sort of thing. So stopping unauthorized peaking, got it?
Speaker 1: And integrity.
Speaker 2: Integrity is about trust, Trust that the data hasn't been
Speaker 2: messed with, that it's accurate, whether it's sitting in a
Speaker 2: database or flying across the network.
Speaker 1: Makes sense, like you wouldn't want someone changing order details
Speaker 1: mid process.
Speaker 2: Exactly or subtly altering content on a website without anyone noticing.
Speaker 3: You need to know what's.
Speaker 1: Reliable and the last one. Availability.
Speaker 2: Availability just means the systems up and running when legitimate
Speaker 2: users need it. Think DIDOS attacks trying to knock a
Speaker 2: site offline. That's an attack on availability.
Speaker 1: Though the source makes a fair point, doesn't it that?
Speaker 1: For web developers, our main focus often ends up being
Speaker 1: more on confidentiality and integrity. Availability sometimes falls more to
Speaker 1: like infrastructure teams.
Speaker 2: Often, Yeah, it's a reasonable distinction in practice. Now, who
Speaker 2: are we defending against the term hacker gets thrown around
Speaker 2: a lot, right. The book outlines a typical attack flow
Speaker 2: starts with reconnaissance, just.
Speaker 1: Gathering info, scoping things out, YEP.
Speaker 2: Finding vulnerabilities, understanding the technology, looking for weak points, all
Speaker 2: the homework before the.
Speaker 1: Actual attempt, and after recon.
Speaker 3: Then comes penetrate.
Speaker 2: That's the initial break in exploiting a weakness found during
Speaker 2: recon to get that first foothold.
Speaker 1: And they don't just stop there, presumably no.
Speaker 2: Way next is often hide evidence, covering their tracks, maybe
Speaker 2: setting up persistent so they can stay in longer without
Speaker 2: being detected.
Speaker 1: Makes sense, want to stick around and it's worth remembering.
Speaker 2: Like the book says, it's not always super technical exploits,
Speaker 2: phishing emails, maybe even a disgruntled employee.
Speaker 3: Those are common ways in two.
Speaker 1: Yeah, the human element. Okay, some key terms the source clarifies. First,
Speaker 1: attack surface, what's the deal there?
Speaker 2: Your attack surface is basically while all the different points
Speaker 2: where an attacker could possibly try to interact with your system,
Speaker 2: think log in forms, APIs, file uploads, anywhere input.
Speaker 1: Is accepted, and the general idea is to make that smaller, right,
Speaker 1: less places to attack.
Speaker 2: Usually yes, minimize the surface, but there's this interesting nuance
Speaker 2: mentioned sometimes increasing the number of attack points, like maybe
Speaker 2: splitting a sensitive function into its own separate API.
Speaker 1: Wait, increasing it helps.
Speaker 2: How it sounds weird, I know, but think about the
Speaker 2: impact if that separate sensitive API gets breached. Maybe the
Speaker 2: damage is contained just to that sensitive data. If it
Speaker 2: was all part of one big application, the breach might
Speaker 2: expose everything, so larger surface potentially smaller blast radius.
Speaker 1: Okay, that's a counterintuitive point. Interesting. Next term security by obscurity.
Speaker 2: Ah, this one the idea you can secure something just
Speaker 2: by hiding it well, like using a weird port number
Speaker 2: or a secret URL. And the verdict is for web apps,
Speaker 2: forget it. It's just not a reliable strategy. The web
Speaker 2: is designed to be found, and scanners are really good
Speaker 2: at finding things no matter how obscure you think you've
Speaker 2: made them. Hiding isn't securing.
Speaker 1: Right, Okay. A core theme that comes up again and
Speaker 1: again is this balance. Security isn't purely technical.
Speaker 2: Absolutely, it's a business decision fundamentally.
Speaker 1: Like that analogy in the source. Yeah, you don't spend
Speaker 1: one hundred bucks to protect a twenty dollars bill exactly.
Speaker 2: The effort has to match the value of what you're protecting.
Speaker 2: Protecting say PII personally identifiable information or PHI personal health
Speaker 2: information that demands way more security effort than I don't know,
Speaker 2: a simple brochure website.
Speaker 1: Higher stakes, more protection, right.
Speaker 2: Leads directly into that classic tension between security and user
Speaker 2: experience or UX.
Speaker 1: Yeah, the more secure often the more annoying for the user. Right,
Speaker 1: more steps, more.
Speaker 2: Friction, totally finding that sweet spot is key. You expect
Speaker 2: MFA and maybe some extra checks logging into your bank.
Speaker 2: You'd be pretty annoyed if a simple form made you
Speaker 2: jump through those same hoops. Context is everything.
Speaker 1: Okay, foundation's laid. Let's shift into some core tech stuff.
Speaker 1: But through that security lens. Cryptography first, symmetric encryption. What's
Speaker 1: the key takeaway?
Speaker 3: Symmetric means same key.
Speaker 2: One key locks the data, encrypts plaintext to ciphertext, the
Speaker 2: same key unlocks it decrypts back to plaintext.
Speaker 1: And the standard now is AES YEP.
Speaker 2: AES based on Rhindale. It's a block cipher. The source
Speaker 2: mentions things like ryandale create encryptor just to give the concept.
Speaker 1: And there's something called an initialization vector in OIV right.
Speaker 2: And IV is basically random data mixed in during encryption.
Speaker 2: Its main job is to make sure encrypting the same
Speaker 2: data with the same key D produces different results each time.
Speaker 1: Ah, so attackers can't spot patterns easily, and it's safe
Speaker 1: to store the IV with the encrypted data.
Speaker 2: Generally, yes, the security comes from the key, not the
Speaker 2: IV's secrecy.
Speaker 1: Okay, that's symmetric. Hashing is different, though totally different.
Speaker 3: Hashing is a one way street.
Speaker 2: You put data in, you get a fixed size string
Speaker 2: the hash out, but you can't realistically go backwards from
Speaker 2: the hash to the original.
Speaker 1: Data, and its main use is in security.
Speaker 2: Two big ones highlighted checking integrity, making sure data hasn't changed.
Speaker 2: You hash it, store the hash later, rehash it, compare
Speaker 2: if they match it's unchanged. Makes sense, And the other
Speaker 2: secure password storage.
Speaker 3: This is huge.
Speaker 2: Instead of storing passwords directly, which is a disaster waiting
Speaker 2: to happen if you get breached, you store a hash
Speaker 2: of the password.
Speaker 1: So when I log in, you hash what I type
Speaker 1: and compare it to the stored hash exactly.
Speaker 2: If the hash is match, you entered the right password,
Speaker 2: but the original password was never stored.
Speaker 1: Smart what about hash collisions cou'd bad.
Speaker 2: It can be a collision is when two different inputs
Speaker 2: happen to produce the exact same hash. If people can
Speaker 2: find collisions easily for an algorithm, it weakens it for
Speaker 2: things like digital signatures and it gets deprecated.
Speaker 3: Think MD five right.
Speaker 1: And for password hashing, salts are absolutely.
Speaker 3: Critical, oh completely vital.
Speaker 2: Assault is just unique random data that you add to
Speaker 2: the password before you hash it. Each user gets their
Speaker 2: own unique salt stored alongside their password hash.
Speaker 1: Why what does that randomness do?
Speaker 2: It kills Rainbow table attacks. Rainbow tables are these huge,
Speaker 2: pre calculated lists of hashes for common passwords. If you
Speaker 2: don't use salts, an attacker steals your database, looks up
Speaker 2: the hashes in their table, and boom, they have the
Speaker 2: passwords for common ones instantly, but with salts.
Speaker 1: If my password is password one T three with SALTA
Speaker 1: and yours is also password one two three, but with salty.
Speaker 2: The resulting hashes will be totally different. Hashing salted plus
Speaker 2: password one two three is different from hashing salt B
Speaker 2: plus password one two three. The attacker's pre computed table
Speaker 2: is useless. They need a separate table for every possible salt,
Speaker 2: which just isn't feasible. The source shows a table demonstrating
Speaker 2: this perfectly.
Speaker 1: Okay, got it, salts defeat pre computation. What are the
Speaker 1: hashing algorithms themselves? SAHA one is a no go.
Speaker 2: Yeah, SAHA one is considered broken. SAGA two family like
Speaker 2: SAHA two, SAHA five, twelve are the current standards and
Speaker 2: dot net core for general hashing.
Speaker 3: But for passwords.
Speaker 1: Specifically, you want something different.
Speaker 2: Yeah, you actually want algorithms designed to be slow and
Speaker 2: resource intensive. Things like PBKDF two be.
Speaker 1: Crypt script slow. Why slow makes.
Speaker 2: It much harder for attackers to brute force guest passwords
Speaker 2: If each hash calculation takes significant time, trying billions of
Speaker 2: combinations becomes incredibly expensive and slow for them. NIST actually
Speaker 2: recommends PBKDF two for password hashing.
Speaker 1: Okay. Quick mention of asymmetric encryption like RSA.
Speaker 2: Asymmetric uses two keys, a public one you can share
Speaker 2: and a private one you keep secret. Encrypt with public,
Speaker 2: decrypt with private, or sign with private, verify with public.
Speaker 2: It's used everywhere like in TLSSSL. The source does mention
Speaker 2: a future concern about quantum computers potentially breaking current algorithms
Speaker 2: like RSA, but that's more of a long term heads up.
Speaker 1: All right, let's pivot to the Web itself connections requests responses,
Speaker 1: but with that security had on HTTPS connections.
Speaker 2: So when your browser hits an HTTPS site, there's that
Speaker 2: SSLTLS handshake. First, it's a complex back and forth using
Speaker 2: asymmetric crypto like RSA to verify the server's identity via
Speaker 2: certificate and securely agree on a symmetric key.
Speaker 1: So asymmetric sets it up, but then they switch to
Speaker 1: faster symmetric encryption for the actual data.
Speaker 3: Precisely.
Speaker 2: The handshake uses random nonsense too to stop replay attacks,
Speaker 2: and your browser checks the certificate against trusted authorities.
Speaker 1: We also need to get the basics of a request
Speaker 1: in response header's body.
Speaker 2: Yeah, understanding what's in those is key. Request headers carry
Speaker 2: browser info cookie stuff like that. Response heaters tell the
Speaker 2: browser what to do. Set cookies give security instructions and
Speaker 2: status codes.
Speaker 1: Status codes four or four not found, five hundred, server error,
Speaker 1: four to one, unauthorized, four to three forbidden. They tell
Speaker 1: a story they really do.
Speaker 2: Four oh one means log in, four to three means
Speaker 2: you're logged in, but nope, not allowed. The source notes
Speaker 2: a small detail ASP met often uses a three zho
Speaker 2: two redirect after a post up when technically a three
Speaker 2: oh three sec other might be more correct according to
Speaker 2: the HDDC spec minor but details count now.
Speaker 1: Security headers these sound important. Server tells a browser to
Speaker 1: be more.
Speaker 2: Secure exactly and often underutilized hsts. Strict transport security is
Speaker 2: a big one. After the first visit, it tells the
Speaker 2: browser only connect via HTTPS from now on for a
Speaker 2: set period. Max age prevents a text that try to
Speaker 2: downgrade you to HTTP, but.
Speaker 1: It only works after that first successful HTTPS connection. Right,
Speaker 1: you still need the initial redirect from HTTP.
Speaker 2: Correct, You still need that HGTPS redirect handled properly first.
Speaker 2: Then there's CSP Content Security policy, hugely powerful against EXSS.
Speaker 1: How does CSP work.
Speaker 2: It's a header listing exactly where the browser is allowed
Speaker 2: to load resources from scripts, styles, images, fonts. You can
Speaker 2: say self only my own domain, lists specific other domains,
Speaker 2: or use nonzs.
Speaker 1: Nanzs like a one time code for scripts sort of.
Speaker 2: You put a unique random value to actionizez one two
Speaker 2: three in the CSB header and also as an attribute
Speaker 2: on your legitimate script tags. The browser only runs scripts
Speaker 2: that have a matching NONCE blocks injected scripts without the.
Speaker 1: Nons clever, But the source mentioned managing conflicts CSPs can
Speaker 1: be tricky.
Speaker 2: It can be, yeah, especially with lots of third party
Speaker 2: scripts or inline styles other key headers. X frame option
Speaker 2: stops clickjacking, preventing others from loading your site in an iframe.
Speaker 2: X content type option stops browsers from guessing file types
Speaker 2: mime sniffing, which can lead to security issues.
Speaker 1: Okay, last bit for this section. Storing data between requests.
Speaker 1: The web's stateless, so we use things.
Speaker 2: Like cookies, hidden fields, and forms each MEL five local
Speaker 2: storage and session storage.
Speaker 1: Cookies in hidden fields are client side visible, tamparable, risky
Speaker 1: for sensitive stuff. You can sign cookies for integrity though.
Speaker 2: Right, but here's a major warning from the source about
Speaker 2: ASP dot net core's default session storage.
Speaker 3: This is really important.
Speaker 1: Uh oh, what's the issue?
Speaker 2: By default, it's tied to the browser session, not necessarily
Speaker 2: the authenticated user session.
Speaker 1: What's the difference? Why is that bad?
Speaker 2: It means the session cookie might hang around on the
Speaker 2: browser even after the user logs out. If someone else
Speaker 2: sits down at that same computer and uses the same
Speaker 2: browser instance before the browser is fully closed, they might
Speaker 2: potentially pick up the previous user's session data because the
Speaker 2: cookie is still there and valid for the browser.
Speaker 1: WHOA seriously, so logging out doesn't reliably kill the session
Speaker 1: data access if the browser stays.
Speaker 2: Open in the default configuration. Potentially yes. The source is
Speaker 2: extremely clear on this. Do not store sensitive data in
Speaker 2: ASP dot net core session state period, use other mechanisms
Speaker 2: tied properly to user authentication state.
Speaker 1: Okay, that is a massive gotcha. Yeah, message received, loud
Speaker 1: and clear. Avoid session for sensitive stuff.
Speaker 2: It's a common pattern from older frameworks, but you need
Speaker 2: to be aware of this default behavior in ASP don.
Speaker 1: Netcre All right, let's shift gears to common attacks. The
Speaker 1: vulnerability buffet, as the source calls it. Knowing the enemy
Speaker 1: helps us defend. First, the classic injection attacks a wass A.
Speaker 2: One, and the king of injection is seql injection. This
Speaker 2: happens when user input gets improperly mixed into database queries, like.
Speaker 1: Building a sequel string by just sticking user input directly
Speaker 1: in select from users where name plus user name.
Speaker 2: From the input plus exactly if the attacker puts in
Speaker 2: something like or one one, the query becomes selectrom users
Speaker 2: whre name or one one, and suddenly the database returns
Speaker 2: all users because one one.
Speaker 3: Is always true.
Speaker 2: The source mentions variations union based to grab data from
Speaker 2: other tables, air based, where you use database error messages
Speaker 2: to figure out the table structure. There's even a screenshot
Speaker 2: example of an error revealing info, and blind techniques where
Speaker 2: you infer data slowly bit by bit.
Speaker 1: The frorst case is something like xbcmdshell running commands on
Speaker 1: the server itself.
Speaker 2: Oh yeah, if the database account has way too many permissions,
Speaker 2: SQL injection can lead to complete server compromise, So the
Speaker 2: defense parameterized queries always. Instead of mashing strings together, you
Speaker 2: use placeholders in your sequel like at username, and provide
Speaker 2: the user input separately as a parameter. The database driver
Speaker 2: handles it safely, treating it purely as data, not executable.
Speaker 1: Code and Entity Framework uses these by default.
Speaker 2: Mostly yes, for standard link queries and things like save changes.
Speaker 2: EF uses parameterized queries, which is great, but there's a buttter.
Speaker 2: The source points out what it calls a boneheaded bug,
Speaker 2: or at least a risky default feature. Asp net core
Speaker 2: apps built with EF migrations might by default prompt you
Speaker 2: in production to apply database schema updates. If the code
Speaker 2: model changes.
Speaker 1: Wait, let the web application change the data base schema
Speaker 1: in production.
Speaker 2: Exactly the database user account for a running web app.
Speaker 2: Should app not have permissions to al your tables or schemas.
Speaker 2: That needs strict control through separate deployment processes. It's a
Speaker 2: dangerous default.
Speaker 1: Yikes. Okay noted Moving on cross site scripting xssas a
Speaker 1: seven different target here right, not the.
Speaker 2: Database, right, EXSS targets the user's browser. The goal is
Speaker 2: to inject malicious JavaScript code that runs in the context
Speaker 2: of your website but in another user's browser session.
Speaker 1: How by getting script tags into places where user content
Speaker 1: is displayed, like comment sections.
Speaker 2: That's the classic way, inject script telored EXSS script into
Speaker 2: a comment and anyone viewing that comment runs the script.
Speaker 2: Attackers get clever though, using case variations like script to
Speaker 2: t encoding the script to bypass simple filters.
Speaker 1: The source showed an I frame example within coded script
Speaker 1: and injecting into HTML attributes like on mouseover.
Speaker 3: Yeah, on mousover dot.
Speaker 2: Malicious code is a common one or hijacking existing JavaScript
Speaker 2: on the page that might process user input insecurely. Some
Speaker 2: older vectors are blocked by modern browsers.
Speaker 1: Now thankfully, what Was that about value shadowing in older
Speaker 1: ASP dot Net?
Speaker 2: Ah? Yeah, in older versions, if you had say doc
Speaker 2: evil in the URL and also a form field named Q,
Speaker 2: the framework might prioritize the URL value made it easier
Speaker 2: for attackers to inject scripts via the URL reflected EXSS.
Speaker 1: Okay, so defense against XSS. How do we display user
Speaker 1: content safely?
Speaker 3: In code?
Speaker 2: And code and code? Before you render any user supplied
Speaker 2: content as HTML, you must encode special characters becomes an
Speaker 2: ltcode becomes NGDA, quotes become a ket quote, et cetera.
Speaker 1: So the browser just shows the characters, it doesn't interpret
Speaker 1: them as code exactly.
Speaker 2: The source contrasts at HTML raw, which is dangerous because
Speaker 2: it skips encoding with safe methods like system, dot net,
Speaker 2: dot web, Utility, dot HTML encode using CSP headers with
Speaker 2: nonsas as we discussed, is another.
Speaker 1: Strong layer right layers of defense. CSP helps limit what
Speaker 1: scripts can run. Encoding stops injection into the HTML structure.
Speaker 2: And a brief mention of malvertizing malicious ads delivering scripts.
Speaker 2: That's a related risk from third parties.
Speaker 1: Okay, next attack, cross site request forgery CSRF. This one
Speaker 1: sounds sneaky.
Speaker 2: It is CSRF forces a logged in user to unknowingly
Speaker 2: submit a malicious request to a website they're authenticated with.
Speaker 1: How does that work?
Speaker 2: Imagine you're logged into your bank and attacker crafts a
Speaker 2: link or a hidden form on say an evil website.
Speaker 2: Maybe it's coded to transfer money. If you click that
Speaker 2: link or even just load the page with the hidden form,
Speaker 2: your browser helpfully includes your bank authentication cookies with the request, So.
Speaker 1: The bank thinks you willingly said the transfer request, yeah,
Speaker 1: because the cookies are valid.
Speaker 2: Exactly, the attacker leverages your authenticated session. The source shows
Speaker 2: examples using simple image tags or auto submitting forms.
Speaker 1: Nasty. How do we stop that?
Speaker 2: The standard defense is anti CSRF tokens. Asp dot core
Speaker 2: has built in support with the validate anti forgery token attribute,
Speaker 2: and they at html dot Anti forgery Token Helper.
Speaker 1: How do those tokens work?
Speaker 2: When the server renders a form, it generates a unique,
Speaker 2: unpredictable token. It put it's this token in a hidden
Speaker 2: field in the form and usually in a cookie. When
Speaker 2: the form is submitted back, the server checks that the
Speaker 2: token from the form matches the token from the cookie, and.
Speaker 1: An attacker on another site can't read the cookie from
Speaker 1: my bank site, so they can't forge their request with
Speaker 1: the right token.
Speaker 2: Precisely the same origin policy prevents them reading the cookie.
Speaker 1: However, another however, what's the catch with the default ASP
Speaker 1: dot net implementation?
Speaker 2: The source points out a potential weakness. While the default
Speaker 2: tokens stop trivial CSRF, they are often reusable for the
Speaker 2: same user session and can remain valid.
Speaker 1: For a while reusable, so if an attacker somehow steals
Speaker 1: a valid token.
Speaker 2: The source describes the scenario where a token captured from
Speaker 2: a user's legitimate request could potentially be replayed later in
Speaker 2: a malicious request from that same user's browser context, maybe
Speaker 2: via XSS, or if the user revisits a malicious site
Speaker 2: while still logged in. The default token isn't strictly single
Speaker 2: use or tied tightly enough to expire immediately when it
Speaker 2: perhaps should.
Speaker 1: Wow. Okay, so better than nothing, but not perfect out
Speaker 1: of the box.
Speaker 3: Needs tightening, seems so.
Speaker 2: The fix involves custom code using IANTI forgery, additional data
Speaker 2: provider or cookie authentication events to make tokens more strictly
Speaker 2: session bound or truly single use. Katcchase can also help
Speaker 2: against automated CSRF attemps.
Speaker 1: Okay, another vulnerability mass assignment.
Speaker 2: This happens when your application blindly accepts and binds all
Speaker 2: data submitted in a request to your back end model object,
Speaker 2: even properties the user shouldn't be allowed to change through
Speaker 2: that specific form or API.
Speaker 1: Call the blog post example from the source right A
Speaker 1: form lets users edit title and content, but the underlying
Speaker 1: blog post object also has like an is published flag
Speaker 1: or a created date.
Speaker 2: Exactly if your update action just takes all submitted data
Speaker 2: from form fields, query, string, et cetera and applies it
Speaker 2: to the blog post object loaded from the database.
Speaker 1: An attacker could add any published true to the URL
Speaker 1: or slip in input type hidden name is published value
Speaker 1: true into the form they.
Speaker 2: Submit yep, And because of default model binding behaviors including
Speaker 2: that value shadowing issue again, the framework might just obediently
Speaker 2: update the es published property even though the UI form
Speaker 2: never showed that field.
Speaker 1: So they bypass authorization checks by manipulating the data binding.
Speaker 1: How do you fix that?
Speaker 2: Use specific view models or data transfer objects DTOs for
Speaker 2: each form or API endpoint. These models should only include
Speaker 2: the properties that are legitimately allowed to be updated in
Speaker 2: that context. Don't bind directly to your full database entities
Speaker 2: for updates coming from the user, be explicit.
Speaker 1: Got it only allowed binding for fields you actually intend
Speaker 1: to change on that screen exactly.
Speaker 2: The source also briefly mentions other things like insecure direct
Speaker 2: object references ide yours like changing order EQUIDLA one two
Speaker 2: three in the URL to order lvdno one two four
Speaker 2: to see someone else's order OS command injection, directory traversal,
Speaker 2: super careful with filepaths, business logic abuse, using the app
Speaker 2: in weird ways, session hijacking, response splitting, parameter pollution, lots
Speaker 2: to be aware of a minefield.
Speaker 1: Okay, let's talk about access control itself authentication first. Proving
Speaker 1: who you are O SPA two. Passwords are the old way, but.
Speaker 2: Problematic, hugely problematic. People choose weak ones reuse them everywhere,
Speaker 2: which leads to credential stuffing.
Speaker 1: Yeah, that's where attackers take lists of leak usernames and
Speaker 1: passwords from one breach and just.
Speaker 2: Try them automatically on tons of other sites. And it
Speaker 2: works depressingly often because of password reuse.
Speaker 1: So we need better than just passwords. Multi factor authentication MFA.
Speaker 2: Using something you know password plus something you have phone
Speaker 2: for a code authenticator app hard work key or something
Speaker 2: you are fingerprint face. It makes credential stuffing much much harder.
Speaker 2: Other defenses include checking logins against breach lists like have
Speaker 2: I Been Pound or detecting logins from weird locations.
Speaker 1: Now the source dives into asp dot it's default authentication.
Speaker 1: It criticizes using email as the username.
Speaker 2: Yeah, because failed login attempts can inadvertently confirm whether an
Speaker 2: email address is registered or not, which is information linkage.
Speaker 2: And it highlights a subtle timing attack vulnerability.
Speaker 1: Timing attack on a login page.
Speaker 2: It's clever and sneaky. An attacker sends lots of logan
Speaker 2: attempts with a known bad password, but tries different usernames.
Speaker 2: The code path inside the application might take fractionally longer
Speaker 2: milliseconds to process a request for a valid username because
Speaker 2: it finds the user than checks the password compared to
Speaker 2: an invalid username, where it fails.
Speaker 1: Faster, and attackers can measure that tiny time difference.
Speaker 3: With automated tools.
Speaker 2: Yes, they can use that timing difference to figure out
Speaker 2: which usernames are registered on the system, even without guessing
Speaker 2: any passwords.
Speaker 1: Wow, that's subtle, it is.
Speaker 2: The fix is to make the code paths for valid
Speaker 2: and invalid user names take as close to the identical
Speaker 2: amount of time as possible constant time comparison logic.
Speaker 1: And there's another warning about asp nets default authentication cookie
Speaker 1: session token similar to the CSRF token thing.
Speaker 2: Yes, another default behavior. To be very aware of the
Speaker 2: source demonstration, it's using tools like burpsuite how the standard
Speaker 2: authentication cookie might be reusable even after the user explicitly
Speaker 2: logs out or after the server side session should have
Speaker 2: logically expired based on inactivity.
Speaker 1: Seriously, so logging out doesn't necessarily invalidate the off cookie
Speaker 1: immediately or reliably. By default, stealing one could give longer
Speaker 1: access than expected.
Speaker 2: Potentially, Yes, the default linkage between the off cookie's validity
Speaker 2: and the service side session state isn't as tight as
Speaker 2: you might assume. It makes cookie theft potentially more impactful.
Speaker 1: Okay, so what's the fix there? Custom code again?
Speaker 3: Pretty much?
Speaker 2: It again involves hooking into cookie authentication events to add
Speaker 2: server side validation, checking a database flag, for instance, to
Speaker 2: ensure the session associated with that cookie is still considered
Speaker 2: valid by the server on every request, not just relying
Speaker 2: on the cookie's own expiration.
Speaker 1: Time makes sense. You need service side control over session
Speaker 1: validity for MFA and ASP dot net. What options does
Speaker 1: the source mention.
Speaker 2: The usual suspects? SMS codes easy but vulnerable to swapping.
Speaker 2: Authenticator apps like Google or Microsoft Authenticator better based on
Speaker 2: TOTP and hardware key is like Ubikey's generally considered strongest uses.
Speaker 2: Protocols like Phytoto, Web.
Speaker 1: Authen and the simple baseline require authentication globally.
Speaker 2: Yeah, using things like authorized folder or global filters is
Speaker 2: a good safety net to prevent accidentally leaving pages unprotected.
Speaker 1: Okay, so that's authentication. What about authorization AISPA five What
Speaker 1: you can do once you're logged in?
Speaker 2: First, let's repeat the mantra because it applies here too.
Speaker 2: Avoids storing sensitive data or authorization decisions purely in session
Speaker 2: state due to that cookie persistence issue.
Speaker 1: Right, So basic authorization roles.
Speaker 2: Role based authorization is the simplest. Define roles like admin
Speaker 2: manager user and use attributes like authorized roles admin manager
Speaker 2: to restrict access to controllers or actions. Easy to understand,
Speaker 2: easy to implement for broad categories.
Speaker 1: But sometimes you need finder control.
Speaker 2: That's where claims based authorization comes in. A claim is
Speaker 2: a specific piece of information about the user like department
Speaker 2: sales or can approve expenses true. You can then create
Speaker 2: policies based on these claims like authorized policy must be
Speaker 2: in sales department much more granular.
Speaker 1: And then there's context specific authorization making sure users only
Speaker 1: see their.
Speaker 2: Own stuff crucial in multi user systems. The source shows
Speaker 2: some neat patterns for handling this, especially with entity framework
Speaker 2: ideas like using custom attributes, say user filterable on your
Speaker 2: database entities, and how would that work? You'd combine it
Speaker 2: with maybe a base repository or helper methods like single
Speaker 2: en user context ITEMID. Behind the scenes, it automatically adds
Speaker 2: a ware x user x user current user a clause
Speaker 2: to the database query based on the logged in user.
Speaker 2: You define a user filter expression once and it gets
Speaker 2: applied consistently.
Speaker 1: Ah, so it builds the user filtering right into the
Speaker 1: data access layer automatically. That sounds way less error prone
Speaker 1: than remembering to add were clauses everywhere.
Speaker 2: It can be a really powerful pattern for venting users
Speaker 2: from accessing data they shouldn't implicitly handling many ID or scenarios.
Speaker 1: If done right, cool, okay, logging air handling OSBA ten
Speaker 1: Why is logging so critical for security, specifically.
Speaker 3: Because detection is key.
Speaker 2: Most standard application logging tracks functional errors or performance. Security
Speaker 2: logging is about spotting signs of an attack. Hackers often
Speaker 2: count on systems not logging the suspicious stuff they do, and.
Speaker 1: The default ASP dot net core log levels aren't really
Speaker 1: cut out.
Speaker 2: For this, not really info warning error critical, they're about
Speaker 2: application health. The source suggests creating custom security log levels
Speaker 2: like what things like security alert, security, audit, security success.
Speaker 2: This lets you specifically tag events like failed login bursts,
Speaker 2: access attempts on sensitive resources, successful logins from new locations,
Speaker 2: potential policy violations, things and security monitoring system should actually
Speaker 2: care about.
Speaker 1: So you filter logs on these custom levels to build
Speaker 1: an audit trail or trigger alerts for security teams.
Speaker 2: Exactly, it separates the security signal from the application noise.
Speaker 2: Honeypots are a great example of using this.
Speaker 1: Honeypots like fake targets.
Speaker 2: YEP setting up decoy resources that look tempting to attackers
Speaker 2: but have no legitimate use, maybe a fake admin login
Speaker 2: page of wpadmin on your non WordPress site or a
Speaker 2: fake sensitive API endpoint.
Speaker 1: And any traffic hitting those is automatically suspicious.
Speaker 2: Highly suspicious. You log any access attempt to a honeypot
Speaker 2: with a high priority security level like security critical. It's
Speaker 2: a great way to detect scanners and bots early. You
Speaker 2: could even use that logging to trigger automated blocking, maybe
Speaker 2: using an attribute concept like block flocked out that the
Speaker 2: source mentions.
Speaker 1: Cliver and on error handling, the key message is.
Speaker 2: Don't swallow errors silently. Users need feedback, but also don't
Speaker 2: show detailed stack traces or internal system information in production
Speaker 2: error messages. Provide a user friendly error page. Log the
Speaker 2: detailed server side for debugging, but don't leak info to
Speaker 2: potential attackers.
Speaker 1: Makes sense, okay. Final stretch in this section setup and
Speaker 1: can figure curation, basic server.
Speaker 3: Hardening, foundational stuff.
Speaker 2: Don't let users upload files directly into folders served by
Speaker 2: the web server. Sanitize user provided filenames, turn off directory browsing.
Speaker 2: Don't use default install paths for servers if possible. Disabled services.
Speaker 2: You don't need cy sugmind one oh one, but.
Speaker 1: Crucial network security firewalls.
Speaker 2: Absolutely segment your network web server, database server, mail server.
Speaker 2: They should be separate, ideally with firewalls between them, allowing
Speaker 2: only the specific ports needed. The database server should definitely
Speaker 2: not be directly reachable from the public.
Speaker 1: Internet secrets management. This sounds critical.
Speaker 3: It is paramount.
Speaker 2: Do not store database connection strings, API keys, encryption keys, passwords,
Speaker 2: and config files like app settings dot json, especially if
Speaker 2: checked into source.
Speaker 1: Control, even if they're encryptive and the canfig file.
Speaker 2: Even then, because now you have the problem of managing
Speaker 2: the decryption key securely. Where do you put that? It
Speaker 2: just moves the problem. Better options are dedicated secrets management
Speaker 2: tools like Hashi Court Vault environment variables and injected securely
Speaker 2: by the hosted platform or perhaps a separate, tightly secured
Speaker 2: configuration database.
Speaker 3: Keep secrets out of your code repository, got.
Speaker 1: It HTTPS everywhere we've covered adding security headers in ASP
Speaker 1: dot net core.
Speaker 2: Usually done in startup dot cs using middleware adding headers
Speaker 2: like x frame options, x content type options, hsts, CSP
Speaker 2: globally for page specific things like maybe very strict caching directives,
Speaker 2: cash control dot no store no cash on a page
Speaker 2: displaying sensitive data. You can often use attributes on the
Speaker 2: controller action.
Speaker 1: Third party components libraries, new get packages.
Speaker 2: Big source of risk. If a library you depend on
Speaker 2: has a vulnerability, your application is vulnerable. So vet your dependencies.
Speaker 2: Use reputable sources, keep them updated and understand the risks.
Speaker 2: The source warns, though, that updates don't catch everything, and
Speaker 2: many vulnerabilities aren't public knowledge.
Speaker 1: Tools like o WASP dependency check help find known issues
Speaker 1: in libraries.
Speaker 2: Yes, Component Analysis SAA very useful for catching known cvees
Speaker 2: in your dependencies.
Speaker 1: What about integrity hashes sub resource integrity.
Speaker 2: That's a browser feature for a third party javascripts CSS
Speaker 2: loaded from CDNs. In your script or link tag, you
Speaker 2: include a cryptographic hash integrity of the file you expect.
Speaker 2: The browser downloads the file, hashes it, and only run
Speaker 2: supplies it if the hash matches yours. Protects against the
Speaker 2: CDN being compromised or the file being modified and transit.
Speaker 1: Neat and finally, test environments need security.
Speaker 3: Too, absolutely key rules.
Speaker 2: Never use real production data and test of environments ever.
Speaker 2: Keep test systems behind firewalls, not exposed publicly. Don't rely
Speaker 2: on it's just a test server. Nobody will find it.
Speaker 2: Obscurity isn't security here either, lock them down.
Speaker 1: Okay, that's a ton of ground on a tax defenses
Speaker 1: and config Let's talk about the ongoing process, a security
Speaker 1: life cycle, testing learning. It's not a one time thing.
Speaker 3: Definitely not. You have to keep testing.
Speaker 2: The source talks about different tool types. First, DAST dynamic
Speaker 2: application security testing.
Speaker 1: These test the running application from the outside like a
Speaker 1: black box hacker tools like burpsuite oas, dayzap exactly.
Speaker 2: They send malicious looking requests probe for common vulnerabilities on
Speaker 2: the live site or API. Good for finding run time issues.
Speaker 2: The downside, they could be noisy, lots of false positives
Speaker 2: and they don't see the underlying code. Using multiple DAFs
Speaker 2: tools can help.
Speaker 1: Then there's SaaS Static Application security Testing.
Speaker 2: SAAST analyzes the source code directly without running it white
Speaker 2: box testing. For dot net there are tools like the
Speaker 2: Prima Security Scanner built in Rosalin analyzers and commercial options.
Speaker 3: They can find.
Speaker 2: Flaws in the code logic that DAST might miss, but
Speaker 2: they also have their own types of noise and limitations.
Speaker 1: And SEA Source component analysis we mentioned checks library dependencies
Speaker 1: for known vulnerabilities.
Speaker 2: Right like OAST dependency check. Crucial Reminder finds known issues only,
Speaker 2: not zero days, not flaws unique to.
Speaker 3: How you use the library.
Speaker 1: I is also mentioned.
Speaker 2: Interactive Application security testing sort of a hybrid. IT instruments
Speaker 2: the running application to combine dynamic testing with runtime code
Speaker 2: analysis still evolving, less common maybe, but promising.
Speaker 1: So lots of tools. What's the big caveat.
Speaker 3: The source is very clear and realistic here.
Speaker 2: None of these automated tools find everything they're good at,
Speaker 2: finding the low hanging fruit, the common, easy to spot vulnerabilities.
Speaker 2: Relying only on scanners will lead to breaches. Their helpers
Speaker 2: supplements not a silver bullet.
Speaker 1: Gotcha tools help but don't replace human review and secure design.
Speaker 1: Callie Linux gets a mention.
Speaker 2: Yeah, the Linux distro packed with security tools. The source
Speaker 2: suggests pragmatically that maybe it's easier just to install the
Speaker 2: specific tools you actually need, like ZAP or BURP, on
Speaker 2: your regular development machine, rather than switching to a whole
Speaker 2: new OS you might not be familiar with.
Speaker 1: Makes sense integrating these tools into CICD.
Speaker 3: That's the goal for many teams.
Speaker 2: Run safety and SEA automatically on every build or pull request,
Speaker 2: maybe fail the build if high severity vulnerabilities are found.
Speaker 2: Helps catch things early. The challenge is managing the findings,
Speaker 2: tuning the tools to reduce false positives.
Speaker 4: Code reviews, specifically for security highly recommended separate from functional reviews,
Speaker 4: have developers specifically look at code changes just through a
Speaker 4: security lens, helps build awareness and spot issues tools might miss.
Speaker 1: And finally, penetration testing hiring the pros.
Speaker 2: Yep, ethical hackers, but the source warns strongly against just
Speaker 2: hiring someone cheap who runs the same automated scanners you
Speaker 2: could run yourself.
Speaker 1: What should a good pen test involve?
Speaker 2: A proper test follows the attacker methodology, reconnaissance, scanning, and enumeration,
Speaker 2: actually trying to gain access, attempting to maintain access, persistence,
Speaker 2: and maybe covering tracks. They should demonstrate the impact of
Speaker 2: the vulnerabilities found.
Speaker 1: Seeing what a skilled human attacker can actually achieve with
Speaker 1: your system.
Speaker 2: That sounds valuable, incredibly valuable for understanding your real world risk.
Speaker 2: For learning more, The source points to resources like the
Speaker 2: Web Application Hackers Handbook, a classic deep dive, the Daily
Speaker 2: Swig for News, Troy Hunt's blog for great practical insights,
Speaker 2: SERTs like CECHCISSP grapped or mentioned too.
Speaker 1: And maybe the best way to learn is just doing it.
Speaker 1: Setting up vulnerable apps and trying to break.
Speaker 2: Them absolutely hands on practice, experimentation, staying curious. That's huge insecurity.
Speaker 1: So wow, we've really journeyed through this material kicked off
Speaker 1: with security fundamentals CIA triad attacker steps dived into crypto
Speaker 1: web basics like htpps and headers, but always with that
Speaker 1: security angle.
Speaker 2: Then hit the big vulnerabilities SQL injection, xss, CSRF, mass assignment,
Speaker 2: looking specifically at ASP dot net Core three defenses and
Speaker 2: importantly those default behaviors you need to watch out for right.
Speaker 1: Like the session state and authentication cookie issues, covered secure
Speaker 1: setup config secrets management, third party.
Speaker 2: Risks, and wrapped up with the testing life cycle dast
Speaker 2: sessed SCA, the limits of tools, importance of code review,
Speaker 2: pen testing and continuous learning.
Speaker 1: The big takeaway seems to be security is not a
Speaker 1: feature you bolt on at the end. It's an ongoing process,
Speaker 1: layers of defense, constant vigilance exactly.
Speaker 2: It's about balancing the tech the business needs, the user experience.
Speaker 2: It never really stops.
Speaker 1: Well, this deep dive was possible thanks to the source
Speaker 1: material you sent our way, and hopefully we've pulled out
Speaker 1: the most critical insights to get you thinking and applying
Speaker 1: these concepts absolutely.
Speaker 2: And remember, while we focused a lot on the technology,
Speaker 2: the code, the configurations, secure systems also rely heavily on
Speaker 2: the people involved.
Speaker 1: That's a great point to end on it It raises
Speaker 1: a big question for all of us, doesn't it. We
Speaker 1: have all these technical controls, these best practices, but how
Speaker 1: do we better bridge that gap to the human element.
Speaker 1: How do we foster that culture of security awareness not
Speaker 1: just among developers but everyone involved to make things truly safer.
Speaker 2: Yeah, something definitely worth mulling over. How do technology and
Speaker 2: people really work together for better security