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