Speaker 1: Welcome to the deep dive. You're here because you want
Speaker 1: to understand the important stuff. Maybe you get those light
Speaker 1: bulb moments, but without feeling like you're drowning in jargon.
Speaker 2: Exactly.
Speaker 1: Today we're tackling a subject that's well fascinating and also
Speaker 1: increasingly vital, web haacking and penetration testing.
Speaker 2: Think of it this way. We're going to explore how
Speaker 2: the security of web applications gets tested, kind of like
Speaker 2: understanding how a security consultant probes a building's defenses right.
Speaker 1: Not to break in, but to find the weak spots
Speaker 1: so they can actually be fixed precisely. And our guide
Speaker 1: for this, our source material is Rafe Block and his
Speaker 1: book Web Haackingarsenal dot pdf. Now this isn't just theory,
Speaker 1: is it. Blog has real hands on experience.
Speaker 2: He does real world security work, finding vulnerabilities, understanding the
Speaker 2: threats that are actually out there right now. So the
Speaker 2: book is a very practical look sort of under the
Speaker 2: hood of web security. Okay, And what's really key to
Speaker 2: grasp is that web security is always changing. I mean,
Speaker 2: new vulnerabilities pop up constantly, attackers find new tricks.
Speaker 1: Yeah, it never stands still not at all.
Speaker 2: So Block's work gives us a valuable, pretty up to
Speaker 2: date view on these challenges.
Speaker 1: So our mission today really is to pull out the
Speaker 1: essential ideas and techniques from Block's book. We want to
Speaker 1: give you the listener a clearer picture of these vulnerabilities
Speaker 1: and how security pros the ethical hackers actually find them. Yeah, okay,
Speaker 1: let's get into it.
Speaker 2: Let's do it. Let's maybe start with the absolute basics.
Speaker 2: How does the web actually work? Block begins there explaining HTTP.
Speaker 1: That's the foundation, right HGTP. You see it HTTP at
Speaker 1: the start of web addresses. Now, one fundamental thing Block
Speaker 1: points out is that HTTP is stateless. What does that
Speaker 1: mean exactly?
Speaker 2: Imagine you're talking to a waiter, but each time you speak,
Speaker 2: it's like they've never met you before. The server doesn't
Speaker 2: automatically remember your previous request.
Speaker 1: Ah okay, so each request is independent.
Speaker 2: Exactly, And because it's stateless, websites need a way to
Speaker 2: keep track of you, right, Like when you log in.
Speaker 2: That's where cookie. When you log in, the server sends
Speaker 2: this tiny piece of data, the cookie, to your browser.
Speaker 2: Your browser then sends it back with every request after that.
Speaker 1: So the server knows, ah, it's still.
Speaker 2: You exactly, it maintains that state.
Speaker 1: Belloch also stresses though that standard HTTP isn't encrypted.
Speaker 2: That's a huge point. It's like sending a postcard. Anyone
Speaker 2: who intercepts it can potentially read it.
Speaker 1: No ideal for logins or credit cards, definitely not.
Speaker 2: That's why we have HTTPS. The S means secure. It
Speaker 2: adds that layer of encryption, usually TLS or SSL, to
Speaker 2: make the communication private.
Speaker 1: Okay, so HTTP is the basic protocol, maybe insecure HDPS
Speaker 1: adds the security layer. What about get, GETEE and post requests?
Speaker 1: Block clarifies those.
Speaker 2: Two right, So when you click a link or type
Speaker 2: a URL, your browser usually sends a GETTT request. Any
Speaker 2: extra bits of information like search terms often end up
Speaker 2: right in the URL.
Speaker 1: Itself visible in the address bar.
Speaker 2: Yep visible, potentially saved in your history server logs that
Speaker 2: can have privacy implications. Think about sharing a link that
Speaker 2: has sensitive search terms in it.
Speaker 1: Good point. You might share more than you intend. So
Speaker 1: what's post Then?
Speaker 2: PST sends data differently. It's in the background, in the
Speaker 2: body of the request, not usually visible in the URL.
Speaker 2: This is typically used for submitting forms, login details, comments,
Speaker 2: that kind of thing.
Speaker 1: Okay, So get shows parameters in the url PST hinds
Speaker 1: them in the request body makes sense. Now, you mentioned
Speaker 1: the tech behind websites is evolving beyond the classic LMP stack.
Speaker 2: Yeah. Absolutely, the traditional L ANDP stack, Linux, Apache, Myseql, PHP,
Speaker 2: it's still around, definitely, But Block points out the rise
Speaker 2: of newer things like micro services, breaking.
Speaker 1: Big applications into smaller.
Speaker 2: Pieces exactly, and serverlest computing where you don't manage servers directly.
Speaker 2: Plus different databases no suite types like Mango dB.
Speaker 1: And these new technologies bring new security challenges.
Speaker 2: They definitely change the landscape. Different potential weaknesses can emerge.
Speaker 1: Okay, so we've got a basic picture of web communication.
Speaker 1: Now how do people actually start looking for vulnerabilities?
Speaker 2: You mentioned reconnaissance, right, intelligence gathering and enumeration. It's the
Speaker 2: recon phase. Block really emphasizes how critical this is, especially.
Speaker 1: You said in things like bug bounty programs where speed matters.
Speaker 2: Absolutely, you need to map out the target thoroughly and quickly.
Speaker 2: He breaks it down into active and passive subdomain enumeration.
Speaker 1: Active versus passive. What's the difference there?
Speaker 2: Active means you're directly probing the target, sending requests, trying
Speaker 2: things out to see what subdomains exist.
Speaker 1: Like knocking on doors kind of Yeah.
Speaker 2: Passive is more about gathering info that's already out there,
Speaker 2: publicly available without directly touching the target systems.
Speaker 1: Like looking at public records or maps instead of knocking.
Speaker 2: Precisely, and blog runs through a whole toolkit for this.
Speaker 2: One of the first techniques is reverse IP lookup.
Speaker 1: So you have the server's IP address, and.
Speaker 2: This lookup tries to find all the domain names hosted
Speaker 2: on that same server uncover hidden parts of an organization's
Speaker 2: online footprint.
Speaker 1: Interesting, okay, what else?
Speaker 2: Port scanning yep n map is common, but Block mentions
Speaker 2: masscans specifically for its speed. It rapidly checks which communication
Speaker 2: ports are open on a.
Speaker 1: Server, and open ports might mean running services.
Speaker 2: Potentially vulnerable services. Yeah, things that might have been overlooked.
Speaker 1: But an open port isn't always a web server.
Speaker 2: Right, Good point. That's where a tool like httpx comes in.
Speaker 2: Block explains it takes the open ports found by masscan,
Speaker 2: for example, and checks which ones are actually running web
Speaker 2: services HTTP or HTTPS.
Speaker 1: Got it, So find open poorts quickly, then verify which
Speaker 1: are web related? What about finding subdomains specifically?
Speaker 2: He mentions shuffles. It uses big lists of common subdomain
Speaker 2: names like blog shop dev and checks if they exist
Speaker 2: for the target domain using various DNS servers.
Speaker 1: Okay, trying common names, Yeah, makes sense.
Speaker 2: Now here's where it gets really clever. I think passive
Speaker 2: enumeration using showdown.
Speaker 1: Showdown the search engine for Internet connected devices exactly.
Speaker 2: Block explains how you can use the unique hash of
Speaker 2: a website's fabcon.
Speaker 1: The little icon in the browser tab that's the.
Speaker 2: One it's unique identifier. It's hash can sometimes be used
Speaker 2: to find other related subdomains that use the same icon.
Speaker 1: Wow, like a digital fingerprint pretty much.
Speaker 2: If two sites share that specific fabcon hash, it's a
Speaker 2: decent clue they might be related. Block even shows how
Speaker 2: to automate finding this with tools like CURL and Showdown's
Speaker 2: own command line tool.
Speaker 1: That's neat. What other passive methods?
Speaker 2: Certificate transparency logs. These are public records of all SSLTLS
Speaker 2: certificates issued. They list domain and subdomain names, so they're
Speaker 2: a gold mine for passive discovery.
Speaker 1: Ah Okay, and web archives like the Wayback Machine YEP.
Speaker 2: Looking at historical versions of a site can reveal subdomains
Speaker 2: that existed in the past, even if they're not live now,
Speaker 2: sometimes they come back online or point to interesting things.
Speaker 1: So digging through history and then there's a mass. You
Speaker 1: said it's comprehensive.
Speaker 2: Yeah, a mass pulls together a lot of techniques, both
Speaker 2: active and passive. Block highlights its different modules, Intel for
Speaker 2: gathering initial info and for the actual subdomain, searching, dB
Speaker 2: for storing results.
Speaker 1: VIZ for visualizing, and track right viz helps you see
Speaker 1: the relationships, and track is great for monitoring changes over time.
Speaker 1: Did a new subdomain appear? Did one disappear? Very useful?
Speaker 1: What about finding hidden files or directories?
Speaker 2: That's directory fuzzing tools like FFUF or deerbuster use wordless
Speaker 2: lists of common directory and file names to guess paths
Speaker 2: on the server.
Speaker 1: Trying to find pages that aren't linked publicly exactly.
Speaker 2: Maybe configuration files, old backups, adamin interfaces, things that could
Speaker 2: hold sensitive info or vulnerabilities.
Speaker 1: Okay, and you mentioned gaffer finding known URLs.
Speaker 2: Yeah, gaff etches URLs for a domain from various public
Speaker 2: sources like the Wayback Machine, Common crawl, etc. It's passive
Speaker 2: gathering of known paths.
Speaker 1: And JavaScript files. You said they can leak.
Speaker 2: Info, Oh, definitely. Block stresses looking inside JavaScript developers sometimes
Speaker 2: accidentally leave comments, internal API en points, maybe even secret
Speaker 2: keys or subdomain names in the code. He uses a
Speaker 2: PayPal example to show how this can happen.
Speaker 1: Wow, just hiding in plain sight in the code.
Speaker 2: Sometimes Yeah, then there's crawling or spidering. Tools like gospeitter
Speaker 2: automatically follow links on a website to map out its structure.
Speaker 1: Building a site map automatically.
Speaker 2: Right and Bolock notes gospitter is good at parsing JavaScript too,
Speaker 2: and even finding things like AWSS three buckets mentioned in the.
Speaker 1: Code, which brings us to cloud stuff s three.
Speaker 2: Buckets, Yeah, Amazon s three storage buckets. Block discusses how
Speaker 2: misconfigured cloud storage is a common problem. If a bucket
Speaker 2: is accidentally made public, it can expose huge amounts of data.
Speaker 2: He points to resources like buckets dot grayhtwarfare dot com
Speaker 2: for finding these leaky buckets across different cloud providers.
Speaker 1: Okay, so that's the recon A lot goes into just
Speaker 1: mapping things out. Now, what weaknesses are they actually looking
Speaker 1: for once they have this map? Server side injection attacks.
Speaker 2: Right, These are really serious because they let an attacker
Speaker 2: inject code that runs on the web server itself. SQL
Speaker 2: injection is the classic example.
Speaker 1: SQL injection heard of. It seems bad. How does it work?
Speaker 2: Basically, you inject malicious SQL database commands into input fields,
Speaker 2: search boxes, log informs, even URL parameter. Sometimes, if the
Speaker 2: application doesn't clean that input properly, the database might run
Speaker 2: your malicious command.
Speaker 1: And that lets you do what steal data.
Speaker 2: Steal data, modify data, sometimes even take control of the database.
Speaker 2: Server block covers different ways to exploit it. Error based,
Speaker 2: where you cause errors that leak info, boolean base asking
Speaker 2: true false questions, time based, making the database pause to infer.
Speaker 1: Things clever, and tools like sql map help automate this massively.
Speaker 2: Sql map is a powerful tool for finding and exploiting
Speaker 2: sqal injection. Block also mentions an interesting angle SQL injection
Speaker 2: via jawts JWTs.
Speaker 1: Yeah, those json web tokens for sessions. Yeah.
Speaker 2: Sometimes if the application decodes a GENWT and uses a
Speaker 2: value from it directly in a database query without proper checks,
Speaker 2: you could inject SQL through the jatabt payload.
Speaker 1: Wow. Okay, And it's not just secle databases right no.
Speaker 2: Sql right Block covers no seqal injection too, using Mango
Speaker 2: dB as an example. You can use special operators like
Speaker 2: two dollars for greater than in your input to trick
Speaker 2: the database logic, maybe bypass a log.
Speaker 1: In okay, beyond databases. Command injection.
Speaker 2: This is injecting operating system commands if an application takes
Speaker 2: user input and passes it directly to a system function.
Speaker 1: Like exec like in no JS you mentioned.
Speaker 2: Yeah, no JS exec is a common example if that
Speaker 2: input isn't sanitized and to tacker could run commands directly
Speaker 2: on the server's operating system. Block even quotes the official
Speaker 2: no JS stocks warning against this.
Speaker 1: That sounds really dangerous full server takeover.
Speaker 2: Potential potentially Yes. Then there's SSTI server side.
Speaker 1: Template injection gumplet injection.
Speaker 2: Web frameworks often use template engines to generate HTML dynamically.
Speaker 2: Think of placeholders filled with data. If an attacker can
Speaker 2: inject template syntax itself.
Speaker 1: Like the special characters the template engine.
Speaker 2: Uses exactly, they might be able to escape the intended
Speaker 2: context and run code. Block gives examples for ginga TOO
Speaker 2: and MECO templates showing how you can achieve remote code
Speaker 2: execution RCE.
Speaker 1: RCE again seems like the ultimate goal.
Speaker 2: Often it's definitely a high impact finding.
Speaker 1: Okay, so those are server side. What about attacks that
Speaker 1: happened in my browser? Cross site SCRIPTINGXSS. Right.
Speaker 2: XSS is about injecting malicious client side scripts, usually JavaScript,
Speaker 2: into a web page, which then gets executed by other
Speaker 2: users browsers, so.
Speaker 1: The bad code runs in the victims browser, not the server.
Speaker 2: Correct block explains DOM based XSS, where the vulnerability lies
Speaker 2: in the page's own JavaScript code rather than the server code.
Speaker 2: He talked about sources where malicious data comes from, like
Speaker 2: the URL and syncs where that data is used on
Speaker 2: safely causing script execution.
Speaker 1: Okay, sources and sinks in the browser's dom.
Speaker 2: He also touches on client side template injections similar to SSTI,
Speaker 2: but happening in JavaScript frameworks in the browser, and he
Speaker 2: details XSS risks in frameworks like Angular JS and React JS.
Speaker 1: Seems like XSS can pop up in unexpected places too.
Speaker 2: File uploads, yeah, block mentions uploading files like SVG scalable
Speaker 2: vector graphics. They look like images, but they're XML based
Speaker 2: and can contain executable script content or even hiding scripts
Speaker 2: and image metadata.
Speaker 1: Sneaky and what can attackers do with EXSS?
Speaker 2: A lot? Unfortunately, steal session cookies to hijack accounts, readerupt
Speaker 2: users to fit login pages, phishing, capture keystrokes.
Speaker 1: To pretty serious consequences. Are their defenses.
Speaker 2: CSP Content Security policy. Yes, CSP is a browser mechanism
Speaker 2: to control what resources, scripts, styles, etc. Page is allowed
Speaker 2: to load. It's a major.
Speaker 1: Defense, but attackers try to bypass it.
Speaker 2: Always block lists, common bypasses, exploiting unsafe inline or unsafe
Speaker 2: evil directives, finding vulnerable third party end points allowed by
Speaker 2: the CSP, using data ris if allowed XSS via JavaScript
Speaker 2: file uploads again, even exploiting browser bugs. Sometimes it's a
Speaker 2: cat and mouse game.
Speaker 1: He also mentions the same Origin policy SOP.
Speaker 2: SOP is fundamental. It stops scripts from one website accessing
Speaker 2: data or properties of another website a different origin, but
Speaker 2: block notes ways. It can sometimes be relapsed or bypassed,
Speaker 2: like using document dot domain.
Speaker 1: Okay, now this next one sounds really interesting dom clobbering.
Speaker 2: Yeah, this is clever. You use HTML elements, specifically their
Speaker 2: ID or name attributes, to create global JavaScript variables on
Speaker 2: the page that can overwrite existing legitimate variables or functions.
Speaker 1: How does that work?
Speaker 2: If you have an element like input eyed some variable
Speaker 2: and some browsers window dot some variable might now refer
Speaker 2: to that input element. Attackers use this to break security
Speaker 2: checks or manipulate page logic Block gives examples of bypassing
Speaker 2: filters or even changing document dot cookie.
Speaker 1: Wow overwriting variables with HTML tags and mutation.
Speaker 2: XSS MXSS is another advanced one. It happens when the
Speaker 2: browser tries to fix broken or weird HTML, and in
Speaker 2: the process of mutating it accidentally creates an EXSS vulnerability
Speaker 2: that wasn't in the original markup. He mentions Mozilla's Bleach
Speaker 2: library for sanitizing HTML to prevent this.
Speaker 1: Okay, lots of ways to attack the client side. What
Speaker 1: about CSRF Cross site request forgery.
Speaker 2: CSRF tricks your logged in browser into sending a request
Speaker 2: to a website you're authenticated to, but without your intention,
Speaker 2: like making you unknowingly change your email address or transfer funds.
Speaker 1: How did that happen?
Speaker 2: An attacker might embed a hidden image, tag or form
Speaker 2: on a malicious site or in an email that points
Speaker 2: to an action you arel on the target site. When
Speaker 2: your browser loads it, it automatically includes your cookies, making the
Speaker 2: request seem legitimate.
Speaker 1: Yikes, so the site thinks I wanted to do that
Speaker 1: action exactly.
Speaker 2: Bollock mentions tools like oh ask, ZAPPP which can help
Speaker 2: generate proof of concepts CSRF attacks for testing.
Speaker 1: Are the defenses tokens.
Speaker 2: Yes, the main defense is using unpredictable unique tokens. For
Speaker 2: each session or request, the server checks for this token
Speaker 2: to ensure the request was intentionally initiated by the user
Speaker 2: on the site itself.
Speaker 1: But attackers try to bypass these tokens too.
Speaker 2: He do maybe by exploiting how the site checks the
Speaker 2: referra or origin headers, or if token validation is inconsistent.
Speaker 2: Block also discusses the same site cookie attribute another defense layer,
Speaker 2: in ways it might be bypassed, perhaps through XSS or
Speaker 2: clever subdomain tricks.
Speaker 1: Okay, let's move to attacking the file system itself directory traversal.
Speaker 2: This is about accessing files outside of the intended web
Speaker 2: route directory by manipulating filepaths, often using sequences.
Speaker 1: The go up one directory command right.
Speaker 2: An attacker might try to read sensitive files like EXCTA
Speaker 2: pass on Linux or configuration files. Block mentions using curl
Speaker 2: path as is to make sure the debt isn't normalized
Speaker 2: away by the tool itself and it's much worse if
Speaker 2: the web app runs with high privileges.
Speaker 1: Okay, reading files, what about creating files?
Speaker 2: Arbitrary file creation? If a vulnerability allows an attack to
Speaker 2: specify the name and content of a file that gets
Speaker 2: saved on the server, that's really bad. They could write
Speaker 2: webshells or other malicious code.
Speaker 1: And local file inclusion LFI.
Speaker 2: LiFi is similar to traversal, but instead of just reading
Speaker 2: a file, the attacker tricks the application into including and
Speaker 2: potentially executing a local files content block uses PHP's read
Speaker 2: file function as an example, but include a require functions
Speaker 2: can sometimes lead to code execution too.
Speaker 1: Okay, filesystem access is clearly bad. What about file uploads?
Speaker 1: We touched on SPGs, but are there other risks?
Speaker 2: Huge risks. Applications often try to restrict uploads to certain
Speaker 2: file types like images only, but attackers try to bypass
Speaker 2: these checks by manipulating the mie type reported by the
Speaker 2: browser or the magic bytes, the first few bytes that
Speaker 2: identify a file type. The block gives a great example
Speaker 2: embedding PHP code into an image's metadata using exit tool.
Speaker 1: So if file looks like a normal jpeg, passes.
Speaker 2: The checks exactly, but if the attacker can later get
Speaker 2: the server to execute that file somehow, maybe through a
Speaker 2: LFI vulnerability, or if the server misconfigures how it handles
Speaker 2: certain image types, the embedded PHP code.
Speaker 1: Runs GOTE execution via image upload clever. Okay, let's switch
Speaker 1: to authentication and authorization.
Speaker 2: Big area, absolutely critical. Authentication is who are you? Authorization
Speaker 2: is what are you allowed to do?
Speaker 1: So? Authentication attacks first username enumeration, trying.
Speaker 2: To figure out valid usernames. Sometimes applications give slightly different
Speaker 2: error messages for user not found versus wrong password, or
Speaker 2: maybe the response time is subtly different. Attackers use these clues.
Speaker 1: Okay, then brute force and dictionary.
Speaker 2: Attacks just trying lots of passwords against known or guest usernames.
Speaker 2: Block mentions using tools like wifas, especially against things like
Speaker 2: HTTP basic authentication pop.
Speaker 1: Up boxes, and bypassing log informs like using PUT instead
Speaker 1: of PSD.
Speaker 2: Yeah, sometimes developers only protect against the expected post request,
Speaker 2: leaving other HTTP methods like put potentially vulnerable to bypass
Speaker 2: log in checks. He also mentions attacking account lockout policies,
Speaker 2: trying to bypass them or maybe even use them to
Speaker 2: lock out legitimate users.
Speaker 1: And kpchas those prove your human.
Speaker 2: Tests they can sometimes be beaten. A lock provides a
Speaker 2: whole process using ocr optical character recognition with Tesseract. He
Speaker 2: shows how to use Selenium to automate grabbing the keytcch
Speaker 2: image and feeding it to Tesseract to read the characters.
Speaker 1: So automating the kptchase solving. Wow. What about password resets?
Speaker 2: Abusing forgot password functionality is common? Maybe the reset tokens
Speaker 2: sent via email are predictable or password reset link poisoning
Speaker 2: tricking the application into generating a reset link that points
Speaker 2: to an attacker controlled server by manipulating the host header
Speaker 2: in the request.
Speaker 1: Okay, so lots of ways to attack the login process.
Speaker 1: What about after log in authorization attacks?
Speaker 2: This is about doing things you shouldn't be allowed to do.
Speaker 2: Privileged escalation is the big one. A normal user gaining
Speaker 2: admin power is due to weak access controls.
Speaker 1: Or idoor insecure direct object.
Speaker 2: References right where you can act as someone else's data
Speaker 2: just by changing an ID number in the URL like
Speaker 2: viewprofile dot PHP, dot user AD one two three to
Speaker 2: user AD one to four. Also general web parameter tampering,
Speaker 2: changing hidden form fields or other parameters to gain advantages.
Speaker 1: You mentioned attacking JWTs earlier with c clay, but other
Speaker 1: attacks too.
Speaker 2: Yes, trying to crack the secret key used to sign
Speaker 2: the JWT using tools like hashcat or the alg none attack,
Speaker 2: changing the algorithm header to none and removing the signature,
Speaker 2: hoping the server blindly trusts the payload if it sees none.
Speaker 1: This seems like a bad oversight.
Speaker 2: If that works, it definitely is. He also covers attacking
Speaker 2: o F two point zero, often used for login with
Speaker 2: Google Facebook. Attackers might try to steal access tokens by
Speaker 2: manipulating the redirectory parameter to send the token to their
Speaker 2: own site.
Speaker 1: Okay and salmonel another login standard.
Speaker 2: Similar issues tampering with the samuel response sent from the
Speaker 2: identity provider back to the application, or signature exclusion attacks
Speaker 2: similar to the JWT nun attack.
Speaker 1: What about multi factor authentication MFA.
Speaker 2: Can sometimes be bypassed, maybe the one time password OTP
Speaker 2: system doesn't have rate limiting, allowing an attacker to quickly
Speaker 2: brute force the code. And webcache deception is another interesting one,
Speaker 2: tricking a webcache like a CDN into storing a sensitive
Speaker 2: user specific page under a generic URL. The next user
Speaker 2: who requests that generic URL gets served the previous user's
Speaker 2: sensitive page from the cash ouch.
Speaker 1: Okay, moving into a release specific area. Business logic flaws.
Speaker 2: Yeah, these aren't standard technical bugs like SQL or XSS.
Speaker 2: Their flaws in the application's intended logic how it's supposed
Speaker 2: to work, but in a way that can be abused.
Speaker 1: Examples the blow.
Speaker 2: Gives several, maybe reusing a session id to manipulate a
Speaker 2: digital wallet balance, or finding ways to duplicate transactions, exploiting
Speaker 2: badly designed validation rules like getting infinite bonuses from a
Speaker 2: self referral program.
Speaker 1: So gaming this system's own rules exactly.
Speaker 2: Or exploiting top up features to steal other user's balances
Speaker 2: bypassing credit limits, changing shopping card items or prices, improperly
Speaker 2: getting around loan amount restrictions, finding ways to get unlimited
Speaker 2: wallet balances.
Speaker 1: Again, it seems wallet balances are a recurring theme.
Speaker 2: Money is always a target. He also covers race conditions.
Speaker 1: Race conditions we're timing matters right.
Speaker 2: When the outcome depends on the sequence or timing of
Speaker 2: multiple threads or processes, for example, adding multiple items to
Speaker 2: a cart simultaneously to exploit a pricing calculation bug, or
Speaker 2: abusing an invitation system by sending multiple requests at once.
Speaker 2: The lock even includes a Python script to help test
Speaker 2: for these.
Speaker 1: Okay, very application specific flaws. Next up, xx SSRF and
Speaker 1: request smuggling.
Speaker 2: Three more heavy hitters. XXSE is XML external.
Speaker 1: Entity injection XML data processing. Right.
Speaker 2: If an application parses XML input from users and allows
Speaker 2: external entities, an attacker can define an entity that points
Speaker 2: to a local file on the server like etc exps route.
Speaker 2: When the XML parser resolves this entity, it reads the file.
Speaker 1: So reading server files via XML can lead.
Speaker 2: To RCE, sometimes yes, depending on the parser and server configuration.
Speaker 1: SSRF server side request forgery.
Speaker 2: This is where you trick the server into making requests
Speaker 2: on your behalf. The vulnerable application makes a request to
Speaker 2: an internal service within the network, or even an external
Speaker 2: site that the attacker couldn't reach directly.
Speaker 1: Why is that bad?
Speaker 2: You can scan internal networks, access internal admin panels, or
Speaker 2: even chain it with other vulnerabilities. Bulock gives an example
Speaker 2: of using SSRF to talk to an internal REDTIS service
Speaker 2: and gain RCE. He includes a Python payload script for that.
Speaker 1: Okay, making the server attack itself or its neighbors and
Speaker 1: request smuggling.
Speaker 2: This one's complex. It exploits inconsistencies in how different servers
Speaker 2: like a front end proxy and a back end application
Speaker 2: server interpret HTTP request boundaries, especially with content length and
Speaker 2: transfer encoding headers. It allows attackers to smuggle a second
Speaker 2: malicious request hidden inside a seemingly normal one.
Speaker 1: Tricky stuff. How about insecure de serialization.
Speaker 2: This happens when an application takes serialized data data converted
Speaker 2: into a format for storage or transmission, and converts it
Speaker 2: back into an object in memory without proper safety checks.
Speaker 1: Serialized data from where user input often yeah, or.
Speaker 2: From cookies parameters. If an attacker controls that serialized data,
Speaker 2: they can potentially craft malicious objects that execute code when
Speaker 2: they're de serialized. Example, a Lock dives deep into PHP
Speaker 2: object injection, explaining serialize and unserialized and PHP's magic methods
Speaker 2: that run automatically during object creation or destruction. He gives
Speaker 2: a file creator class example and mentions a real sugar
Speaker 2: CRM vulnerability.
Speaker 1: No get Php. What about other languages?
Speaker 2: He briefly covers dot Net, mentioning binary formatter and ASP,
Speaker 2: dot Net view state, and tools like whyso serial and
Speaker 2: blacklist three and Java insecurity serialization Java do big time.
Speaker 2: He explains Java's read object and write object, the concept
Speaker 2: of gadget chains, sequences of classes that can be abused
Speaker 2: during the serialization, libraries like Apache Commons collections that often
Speaker 2: contain useful gadgets, and again the y serial tool for
Speaker 2: generating payloads.
Speaker 1: So de serializing untrusted data is dangerous across.
Speaker 2: Languages, very dangerous. Always validate or avoid it if possible.
Speaker 1: Okay. Let's pivot to testing specific types of services, web
Speaker 1: services and cloud services.
Speaker 2: Right Block covers SOAP first, simple object access protocol, older style.
Speaker 1: Web service REXML based right YEP.
Speaker 2: Envelope header body structure. He talks about finding the WSDL
Speaker 2: file which describes the service and potentially invoking hidden methods
Speaker 2: not listed in the WSDL and.
Speaker 1: Rest APIs more common now.
Speaker 2: Much more common, representational state transfer, more of an architectural
Speaker 2: style than a strict protocol. Block discusses finding endpoints using
Speaker 2: tools and looking for common descriptor files like swagger, dot
Speaker 2: json or open api specs.
Speaker 1: GRAPHQL. The query language for.
Speaker 2: APIs yeah, graph cuil is different again, usually just a
Speaker 2: single graphere endpoint where you send queries. He mentions tools
Speaker 2: like all tear for crafting queries and the importance of
Speaker 2: introspection queries which ask the API to describe its own
Speaker 2: structure or schema.
Speaker 1: Okay, and serverless functions as a service.
Speaker 2: Like AWS lambda or azure functions. Block explains key features,
Speaker 2: ATI Gateway's routing, requests, the event driven nature, cost savings.
Speaker 2: He gives a no JS lambda example and then shows
Speaker 2: a vulnerable one that accidentally exposes AWS credential ouch.
Speaker 1: Can they have standard vulnerabilities too?
Speaker 2: Absolutely? He highlights command injection in serverleist functions using OOS
Speaker 2: serveralist code as a learning resource. Just because it's serveralist
Speaker 2: doesn't mean it's automatically secure.
Speaker 1: Good point. Now, what about newer HTML five features? Do
Speaker 1: they introduce risks?
Speaker 2: They can? Yeah? The block covers cores, cross origin resource sharing,
Speaker 2: misconfiguring cores headers can weaken the same origin policy, potentially
Speaker 2: enabling attacks like DOMXSS.
Speaker 1: Okay. Web storage global storage session.
Speaker 2: Storage convenient for storing data in the browser, but risky
Speaker 2: if you store sensitive info there. Unlike cookies, there's no
Speaker 2: built in HTTP only flag, so if an attacker gets EXSS,
Speaker 2: they can easily read anything in web storage, potentially stealing
Speaker 2: session data stored there.
Speaker 1: Index DP the browser database.
Speaker 2: Similar risks it's a client side database. If an attacker
Speaker 2: can inject malicious data into it, maybe via EXSS, and
Speaker 2: that data is later read and used unsafely by the application,
Speaker 2: it can lead to stored DOM EXSS or second order EXSS.
Speaker 1: Web messaging post message.
Speaker 2: Use for communication between different windows or frames. The key
Speaker 2: vulnerability here is failing to validate the origin of the
Speaker 2: message center. If you accept messages from anywhere, an attacker's
Speaker 2: malicious page could send messages to your app, potentially triggering
Speaker 2: DOM EXSS web workers for background JavaScript they run scripts
Speaker 2: in the background. Baylock notes potential for denial of service
Speaker 2: don DOM by spawning too many workers or even using
Speaker 2: them for distributed tasks like password cracking, offloading work to
Speaker 2: the user's.
Speaker 1: Browser, and clickjacking.
Speaker 2: That's tricking a user into clicking something they didn't intend to,
Speaker 2: often by loading the target site in a transparent iframe
Speaker 2: overlaid on top of something else. Defenses include the x
Speaker 2: frame options header or the frame ancestors directive. In csp
Speaker 2: UI redressing is a similar concept.
Speaker 1: Okay, a lot of potential pitfalls with HTML five now
Speaker 1: Web application firewalls low BFS. They're meant to stop attacks.
Speaker 2: Right they are dallyfs sit in front of web apps
Speaker 2: and try to filter out malicious requests based on known
Speaker 2: patterns for attacks like cqixss, etc.
Speaker 1: But pentesters need to get around them first.
Speaker 2: You try to figure out which WF is being used, fingerprinting,
Speaker 2: block mentions, looking at HTTP headers, cookie values, specific cookie
Speaker 2: set by products like Citrix, NetScaler or Barracuda.
Speaker 1: Okay, identify the enemy then bypass it. He gives lots
Speaker 1: of exss bypass examples a ton.
Speaker 2: It shows how complex evasion can be. Things like changing
Speaker 2: character case script instead of script, injecting white space or
Speaker 2: comments using alternative tags like SVG or iframe, src doc,
Speaker 2: different event hands form action on input on drag using
Speaker 2: data urs wow using lesser known event handlers, manipulating the
Speaker 2: location object in JavaScript, unicode separators, various encoding or obfustation tricks,
Speaker 2: using alternative execution sinks like set time out or set
Speaker 2: interval or the function constructor instead of direct script tags.
Speaker 2: It's an arms race.
Speaker 1: Definitely sounds like it. Finally, after finding all these vulnerabilities,
Speaker 1: you have to report them right.
Speaker 2: Report writing absolutely crucial. A finding is useless if you
Speaker 2: can't communicate it effectively. Block stress is understanding your audience.
Speaker 2: Are you writing for technical staff who need details or
Speaker 2: executives who need the business impact?
Speaker 1: So tailor the report. What are the key parts?
Speaker 2: An executive summary, high level business language, a finding summary,
Speaker 2: maybe a historical comparison if it's a repeat test. The
Speaker 2: methodology used a narrative of the testing risk assessment CBSS scores,
Speaker 2: but also considering business context, maybe a risk matrix.
Speaker 1: And the technical details, yes.
Speaker 2: The detailed technical report. Each finding needs clear, evident steps
Speaker 2: to reproduce it and recommendations for fixing it. He also
Speaker 2: mentions organizing the report logically and tools that can help
Speaker 2: like Dratus, attack Forge or even using AI like chat
Speaker 2: GPT to assist with drafting.
Speaker 1: Any final tips on writing good reports clearly convey the impact.
Speaker 2: Why should the business care about this vulnerability? Use real
Speaker 2: world examples if possible, make it easy for them to
Speaker 2: understand the risk and prioritize fixes.
Speaker 1: Okay, that was a lot a comprehensive tour.
Speaker 2: It really covers the breadth of modern web haacking. We've
Speaker 2: gone from the basics of HTP through detailed recon server
Speaker 2: side flaws like SEQY and SSTI, client side like EXSS and.
Speaker 1: CSRF filesystem attacks, off issues, business logic flaws xx E,
Speaker 1: SSRF de serialization, attacking APIs and serverlests.
Speaker 2: HTML five issues, WAF bypasses, and finally reporting. It really
Speaker 2: shows the multiple layers.
Speaker 1: Involved and this is all drawn from that real world
Speaker 1: perspective in rafe blotch web haacking arsenal. It's a look
Speaker 1: at how the pros actually do it.
Speaker 2: Absolutely, it highlights the practical techniques used to find weaknesses
Speaker 2: and the applications we all rely on.
Speaker 1: Which leads to maybe a final thought for you listening.
Speaker 1: Given everything we've just discussed all these different types of vulnerabilities.
Speaker 2: It's worth thinking about how these often invisible weaknesses might
Speaker 2: be impacting the security and privacy of the websites and
Speaker 2: apps you use every single day.
Speaker 1: Yeah, security is this constant background process, this layer we
Speaker 1: don't usually see, but it has potential failure points everywhere.
Speaker 2: It really demands constant vigilance from developers and testers.
Speaker 1: We definitely encourage you to explore these topics more if
Speaker 1: you're interested, maybe even check out Block's book for the
Speaker 1: full deep details. Web security is always.
Speaker 2: Evolving, Continuous learning is essential in this field.
Speaker 1: Well, thanks for taking this deep dive with US today