Hacker101 - The Web In Depth

Summary

In this Hacker101 session, the core concepts of web technologies and their implications for security are thoroughly explored. From dissecting the anatomy of HTTP requests to understanding the nuances of cookie security, the video provides a comprehensive overview of essential elements that impact web vulnerability. The session covers critical security concerns such as cross-site scripting (XSS), cross-site request forgery (CSRF), HTML parsing discrepancies, and the importance of HTTP headers. Additionally, viewers are introduced to complex topics like Same Origin Policy, content sniffing, and Cross-Origin Resource Sharing (CORS), all crucial for safeguarding web interactions and data transfer.

Highlights

• HTML parsing involves more than browsers; firewalls examine HTML too, which can create security gaps! 📜
• Cookies must be properly scoped to avoid unauthorized access—domain-specific rules are essential! 🔐
• Parsing discrepancies between web application firewalls and browsers can expose vulnerabilities like XSS. ⚔️
• UTF-7 encoding can bypass filters due to lack of awareness—understanding encoding is key! 🎭
• Content and MIME sniffing still important—IE6/7 were vulnerable, affecting cross-site scripting! 🖼️
• Without Same Origin Policy, the web would be chaos—careful consideration is needed for security! 🕸️
• Cross-Origin Resource Sharing (CORS) and document.domain can introduce risks—approach with caution! 🚨
• CSRF attacks are ubiquitous—tokens are a necessary defense to verify request legitimacy! 🕵️

Key Takeaways

• Understanding HTTP requests is crucial for web security. Learn about methods, paths, headers, and bodies! 🌐
• Cookies have specific security rules—understand domain patterns and the implications of improperly scoped cookies! 🍪
• HTML parsing discrepancies can lead to vulnerabilities—browsers and firewalls might process HTML differently! 🔍
• Cross-site Scripting (XSS) can exploit parsing inconsistencies—stay vigilant on how scripts are interpreted! ⚠️
• Same Origin Policy (SOP) is vital for web security—keep an eye on protocol, domain, and port matching! 🚦
• Always specify mime types and encodings. Understanding content sniffing can help prevent vulnerabilities! 🔒
• Cross-Origin Resource Sharing (CORS) enables safer cross-domain requests—explore its nuances for secure web design! 🛡️
• Cross-Site Request Forgery (CSRF) is common and dangerous—implement CSRF tokens to validate request origins! 🔑

Overview

In this engaging Hacker101 session, we dive deep into the structural workings of the web and the cracks that pose security risks. The discussion opens by unpicking HTTP requests and delving into how various headers, like host and authorization, play pivotal roles. The lesson emphasizes understanding HTTP's foundational structure, which is often the first line of defense against web vulnerabilities.

Moving on, the session uncovers the often overlooked territory of HTML and cookie security. Here, the risks of improper cookie domain scoping and HTML parsing discrepancies are brought to light, with practical examples of how these missteps can lead to significant vulnerabilities such as XSS. Such insights highlight the importance of meticulous attention to detail in web security practices.

The session rounds off by tackling cross-site issues, such as Cross-Site Request Forgery and Cross-Origin Resource Sharing. These complex topics reveal how attackers manipulate request origins and sharing protocols, underscoring the need for robust security measures like CSRF tokens and precise origin policies. All in all, it's a thorough exploration into the realms of web security—educational yet entertaining!

Chapters

• 00:00 - 00:30: Introduction The chapter 'Introduction' covers the basic concepts of the web and their impact on security, including HTTP, HTML parsing, and cookies. It also introduces CSRF attacks and related security topics. The chapter starts by discussing the structure of an HTTP request, highlighting the main components such as methods (GET, POST, DELETE, PUT) and the request path.
• 00:30 - 02:00: HTTP Requests and Headers The chapter 'HTTP Requests and Headers' covers the fundamentals of HTTP requests, focusing on the structure and components involved. It explains the basic format, which includes the verb, resource locator, and headers, followed by the body of the request. The headers—such as host, user agent, and accept—are discussed, emphasizing their role and the importance of correctly parsing and understanding them. Additionally, it references 'burp' as a tool where such headers are frequently encountered. The chapter clarifies that headers and bodies are separated by two CRLF sequences, contributing to a comprehensive understanding of HTTP requests within web development and network communication contexts.
• 02:00 - 04:30: Understanding Cookies This chapter, titled 'Understanding Cookies,' begins with a breakdown of several important HTTP headers used in web communication. It explains the function of the 'host' header, which indicates the host server that will handle a given request. Additionally, it discusses the 'accept' header, which specifies the MIME types that the client can process. This is particularly useful for defining the format of responses, such as when a client requests JSON or XML output from a web service endpoint. The chapter highlights the practical use of these headers in structuring requests to ensure compatibility with web services.
• 04:30 - 10:00: HTML Parsing and Security The chapter titled 'HTML Parsing and Security' dives into the intricacies of HTTP headers and their roles in web security, focusing particularly on cookie management. It explains how cookies are passed via the cookie header to servers, impacting security and session management. Additionally, the referer header is explored, revealing how it tracks the navigation path leading to a request. Authorization headers, crucial for basic authentication processes—and notably different in handling methods such as NTLM for 'NT-style' logins—are also discussed, with an emphasis on the limitations of basic authentication methods in terms of security.
• 10:00 - 16:00: Sniffing and MIME Types The chapter discusses the concept of sniffing and MIME types, with a focus on basic authentication in web communication. It explains that basic auth uses a base64 encoded string combining the username and password, which can easily be decoded using tools like Burp Suite. The simplicity and vulnerability of basic auth are emphasized, highlighting the ease of accessing sensitive information. Additionally, the chapter touches on the nature of cookies as key-value pairs used for storing session data.
• 16:00 - 21:00: Same Origin Policy (SOP) The chapter delves into the concept of cookies in web architecture, explaining how these small pieces of data are stored on the client side for fixed periods, which are defined by either the server or added via JavaScript. These cookies are sent with each request to their designated domain, hinging on specific domain-matching patterns which could either be specific or general enough to apply to subdomains. The discussion highlights the significant security implications, as cookies are continuously transmitted to their intended server or domain.
• 21:00 - 25:00: Cross-Origin Resource Sharing (CORS) The chapter discusses the security aspect of cookies in the context of Cross-Origin Resource Sharing (CORS). It highlights potential security breaches such as setting cookies on domains where one is not supposed to, indicating that improper handling can lead to security vulnerabilities. The chapter begins to explain how cookies work by stating that cookies added to a domain can be accessed by its subdomains, while those added to subdomains are more restricted in accessibility.
• 25:00 - 28:00: Cross-Site Request Forgery (CSRF) The chapter discusses the domain-based restrictions on setting cookies. It explains that a subdomain can set cookies for itself, its own subdomains, and its parent domain. However, it cannot set cookies for its sibling domains. For example, the subdomain 'test.example.com' can set cookies on 'example.com' (its parent) and 'foo.test.example.com' (its child), but not on 'test2.example.com' (its sibling).
• 28:00 - 29:00: Conclusion and Key Takeaways In this chapter, the focus is on the importance of cookie scoping within web domains. The discussion highlights common errors where cookies are scoped in a manner that insecure or unauthorized code can access them. This often occurs when cookies are improperly scoped, allowing code from sibling, parent, or subdomains to access and potentially manipulate them. Key takeaways include the necessity of maintaining a strict hierarchy and secure practices to prevent unauthorized cookie access.

Hacker101 - The Web In Depth Transcription

• 00:00 - 00:30 hi and welcome back to hacker 101 in this video we're gonna be talking about the basic concepts of the web and how they affect security HTTP HTML parsing cookies and more then we're going to talk a little bit about sea surfer tax and other related things let's get started everyone here has probably seen an HTTP request you can see one displayed below there are a couple main parts to it you have your method get post delete put you have the request path that's going to be requested in this case just slash
• 00:30 - 01:00 the route and then you have a number of different headers host user agent except things like that all of you have probably seen this many many times and if you haven't you're gonna see a ton of them in burp this is the main form of a request as I said the basic format is just verb resource locator and then your headers and then your body headers are separated from the body by two crlf sequences
• 01:00 - 01:30 in this case here's a breakdown of just a couple headers that are used there and some other common ones so you have your host header which indicates which host is actually going to handle that request you have the accept header which indicates which mime types are accepted by the client that's often used to specify JSON or XML output in the case of web services if you're making a request to some endpoint and you want to specify that you want XML output for instance then you can just send up except text slash XML
• 01:30 - 02:00 the cookie header is able to pass cookie data to the server and we're gonna talk a little bit more in depth about cookies in a few you have the refer header which shows you which page actually led to that request then you have the authorization header that's used for basic auth pages usually there are a couple different forms like ntlm for NT style logins the basic auth is what most people use this does not do any form of
• 02:00 - 02:30 encryption or anything like that rather it just has the text basic and then a base64 blob of the username : the password basic auth you'll see quite often and if you do see it in burp it's easy to take that base64 Bob throw it into the decoder and immediately see what the username and password were so it's really handy to be able to do that so as most of you know cookies are just key value pairs of data they're stored
• 02:30 - 03:00 on the client for a fixed period of time sometimes those periods are very long but it's always a fixed period and those come from the server or are added by JavaScript and then are sent up with each request to the domain that they're scoped for each cookie has a domain pattern that it actually matches sometimes that's very specific sometimes it's matching a root domain and it'll fly to any subdomains this has security implications in that cookies are going up to one place where
• 03:00 - 03:30 they shouldn't be then you can have some nasty things here likewise if you can set cookies on domains where you're not supposed to that would also be a breach of security so how are cookies secured [Music] well there are a couple simple rules for how cookies actually work cookies added for example calm can be read by any subdomain of example calm cookies added for a subdomain can only
• 03:30 - 04:00 be read in that sub domain and its children a subdomain can set cookies for its own subdomains and its parent but it can't set cookies for sibling no-man's what that means really is that let's say you have the subdomain text example.com it can set cookies on example.com because that's its parent and it could set cookies on food test example.com which is its child domain its own sub domain but it couldn't set them on test2
• 04:00 - 04:30 example.com because that's a sibling domain you have to keep that hierarchy in mind when you're thinking about the scoping of cookies and that's something you're going to see people mess up a whole lot you're going to see people scoping cookies where unauthorised code or insecure code potentially is running alongside secure code and can access the same cookies and manipulate the cookies of parent domains or subdomains
• 04:30 - 05:00 [Music] so that's something you really need to keep in mind in addition you have two flags that you can apply to cookies and the user sent when the server actually sends a cookie down to a client and those are secure which means that the cookie will only work on HTTP pages it'll never be sent up in pure plain HTTP requests only HTTPS and then the confusingly named HTTP only cookie which
• 05:00 - 05:30 doesn't do the opposite of secure what it does rather is make sure that it only sends the cookies up with web requests it won't allow you to read those cookies from JavaScript normally you can use the document.cookie variable in javascript and actually get a list of all the cookies that are applied or that are in scope I should say and you can also manipulate them that way but with the HTTP only flag they'll only be sent up in their quest they won't show up in
• 05:30 - 06:00 JavaScript and if I recall correctly setting those in JavaScript will not actually set those values so those are applied in the setcookie header that actually sets those now let's talk about HTML a little bit it seems non obvious that hTML would actually be an important thing to learn about in this class just because everyone here is seen HTML you've
• 06:00 - 06:30 probably seen it many many times probably everyday but there are a couple weird quirks about HTML that most people don't think about in a security context [Music] for instance what spec you parse HTML against actually really matters generally speaking that's going to be html5 for most sites now or at least most modern sites but the thing is that HTML isn't
• 06:30 - 07:00 just parsed by your browser it's also parsed by things like web application firewalls which sit in front of an application and look for things like cross-site scripting and things of that nature if they're parsing HTML in a different way than your browser is if there's any discrepancy between the two that will often result in a security vulnerability that you can exploit the canonical example here is a pretty simple cross-site scripting vulnerability instead of just a script
• 07:00 - 07:30 tag that has alert 1 in it in this case we have a script that has a source but here's the interesting thing here instead of just script as the tag name we have script slash XSS what that will do in a browser is absolutely nothing it will parse it as a script tag it'll treat the slashes whitespace and you'll end up with an empty XSS attribute on that tag but a web app firewall that is improperly
• 07:30 - 08:00 parsing HTML which is most of them will see that as a script slash XSS tag and it'll let it straight through the filter nowadays they've gotten better usually they're not quite this dumb but they're still pretty dumb and really it's an uphill battle where every time there's a simple discrepancy between the HTML parser in the browser and in a wife or other intermediate you're going to have nasty problems
• 08:00 - 08:30 and you're gonna see this pop up time and again [Music] the other thing is that browsers are built to handle the web obviously if a browser doesn't work for most web pages it's going to have some problems and most web pages are broken in some way or another so there's a lot of legacy parsing in browsers and in html5 there's actually specifics on how that legacy parsing should happen we're gonna talk a little bit more about this in the XSS
• 08:30 - 09:00 session but here are two really good examples of how this can work you have a script tag on its own the browser will automatically close it at the end of the page you may end up with some syntax errors in there but that's fine if it's automatically closed this seems irrelevant if you've already got the ability to add HTML into the page but let's say that it's a cross-site scripting in the URL and you can't get a slash in there because it's parse is a path separator this is a case that I've
• 09:00 - 09:30 seen on a number of occasions and that's something you really have to keep in mind in addition a tag that's missing its closing angle bracket we usually be automatically closed by the angle bracket of the next tag it will end up with a lot of irrelevant attributes and some funkiness in there but having an open angle tag inside of another tag is valid according to most browsers and this again can throw off things like what about firewalls an old
• 09:30 - 10:00 trick was to actually wrap script tags an additional set of angle brackets which would get it right through a web app firewall and parse properly in the browser so keeping in mind these weird discrepancies in HTML parsing and how you think about things is a really good way to actually find ways to get around filters we're gonna talk a ton more about filters very shortly [Music] now some of you may know about content
• 10:00 - 10:30 sniffing content sniffing is where you can send data to the browser without giving it all the information about what it is you're sending it and it'll sort of fill in the blanks examples of this are mime type sniffing where it tries to figure out what type of file you're sending it encoding sniffing where you're checking what sort of text encoding you're sending it so ASCII utf-8 Shift jazz whatever it'll sniff the content to see if it matches certain
• 10:30 - 11:00 heuristics and then it will use those behaviors inside of the browser [Music] mime sniffing is one of the ones that used to bite a lot of browsers it's not so common anymore at least not as a security relevant issue but the browser will often not just look at the content-type header it'll also look at what's on the page if it has enough markers that make it look like HTML the browser will treat it as
• 11:00 - 11:30 HTML [Music] in ie6 and 7 there were cases where image and text files that didn't have proper mime type set down and contained enough HTML what actually executes is HTML so you can get cross-site scripting in a stored fashion very trivially on ie6 and 7 [Music] obviously those are old now but you still find these installed in enterprises ie6 and 7 bugs still a big
• 11:30 - 12:00 issue so these are still things that you should look for where you don't have appropriate mime types and really know how to detect them and how to actually prevent those [Music] so imagine you have a site with file uploads for profile pictures say Facebook if that file that you upload contains just enough HTML to trigger those sniffing heuristics an attacker could upload a picture that contains a
• 12:00 - 12:30 lot of HTML and then just link it to their victims as an innocent picture at that point they're able to execute anything that user can in the context of where that file was uploaded this is one of the reasons that Facebook and other sites use separate domains to host pictures and videos everything like that and we're gonna talk a little bit more about separate domains in a moment with same origin policy which is what really governs cross domain accesses
• 12:30 - 13:00 [Music] so I mentioned encoding sniffing and here's a really weird case you have pages with all different sorts of content on them all the time a lot of you came from hacker news hacker news doesn't convert everything to the same encoding type so the browser will actually see okay I have a character that doesn't make sense in this encoding I'm gonna try and sniff it instead and you'll end up with a page with a bunch of mangled symbols happens pretty often
• 13:00 - 13:30 even in modern browsers [Music] if you don't specify an encoding the browser will automatically apply these heuristics and if you can control the way that the browser decodes text you may be able to alter the parsing and you can also get around filters [Music] a good example is putting you tf7 text into cross-site scripting payloads now most people aren't familiar with you tf7 it's not very common UTF seven is
• 13:30 - 14:00 basically 7-bit ascii with embedded base64 blocks for extended range characters so any of your Unicode characters that don't fit into seven bits you basically have a base64 block that's blocked off with a plus and a minus and that will the code to that character so you can see the payload there is really just a script tag with an alert app this will go straight
• 14:00 - 14:30 through HTML encoding so if you throw this on Facebook it will go there no problem there are no unsafe characters there what there are are unsafe UTF seven characters ie eight and below along with opera earlier versions of Firefox things like that we'll see that in a page and automatically switch the parsing to UTF 7 mode and then those will just be decoded like any other character this
• 14:30 - 15:00 can be an effective way to get around firewalls web app firewall specifically because if they're looking for say angle brackets and double quotes standard characters that we always filter out they're not going to be looking for you tf7 same thing goes for if they're expecting a ski just plain ASCII or utf-8 you send at utf-32 characters you're gonna get straight through the filter there - I
• 15:00 - 15:30 had a client that was trying to sanitize xml coming from unauthorized sources or other untrusted sources and they didn't take into account the fact that they could specify different xml encodings so i started sending up utf-32 and things like that and it would go straight through the filters where they were trying to sanitize this XML similar case happens here except that the encoding is automatically determined by the browser
• 15:30 - 16:00 if you don't specify an encoding so the rule here is you should always be specifying an encoding and know what encoding the browser should be parsing it in so that the server and the client don't have a discrepancy same thing goes for mime types always specify mime types no matter what even if you're just sending an octet stream always set mime types no matter what
• 16:00 - 16:30 so same origin policy is really the backbone of web security today without same origin policy you wouldn't have the ability to move data between subdomains you wouldn't have locks between separate domains things like that is really what underpins browser security now [Music] so what is it it's what domains you can contact via XML HTTP requests Ajax
• 16:30 - 17:00 requests as we normally call them it also restricts access to the Dom across frames and windows so if you open up a new window with JavaScript you may or may not have access to the Dom in that new window what determines that same origin policy this is what prevents you from making Ajax requests across domains with the exception of course requests which we're also going to talk about in a few minutes same origin policy is really what
• 17:00 - 17:30 prevents you from wreaking havoc on the web and any time that it's circumvented in some way bad things happen for just about everyone on the web [Music] so there's this concept of origin matching in SOP and it's much much much more strict than cookies are first of all the protocols must match you can never cross the HTTP HTTPS boundary ever
• 17:30 - 18:00 port numbers must match usually these are you know 84 43 whatever and then domain names must be an exact match there's no wild carding you can never go up or down subdomains any of that it must be an exact match [Music] it is possible to loosen SOP so you can change document.domain
• 18:00 - 18:30 in JavaScript [Music] and that will allow you to change which subdomain in essence you are able to communicate with and there are a number of rules around this you can also do message posting with the post message function for instance in JavaScript and then you have course which again we'll talk about in just a moment [Music] these all open up a lot of different interesting avenues for attack they all
• 18:30 - 19:00 open up things that you would never expect [Music] for instance you can always call postmessage into an iframe how many sites that actually receive messages validate them properly the answer pretty much none of them mind you it's a rare thing to actually see this happen but when you do see message handling inside of a web app they almost always handle it wrong in addition this was used to break a lot of Chrome extensions Chrome
• 19:00 - 19:30 extensions are very limited in what they can do inside of their sandbox so the youth post message to move around [Music] because you're able to always post to these extensions because of the way that they break the sandbox in effect they were vulnerable to cross-site scripting a lot of cases and this could even be used to jump from one web page or one tab to another through these extensions [Music] this has been a source of pain
• 19:30 - 20:00 repeatedly and no one really has any decent solution generally speaking if you don't have a very very good reason to do it you shouldn't loosen the SOP there's usually a design problem there if you're trying to do that [Music] so Korres is cross origin resource Shang basically it allows you to make requests across domains outside of SOP using XML
• 20:00 - 20:30 HTTP requests orders also comes into play with WebGL in that it can read textures across domains but cores is still really new and then Abel's some kind of risky situations what's interesting is that you can actually make it has received domains cookies so if you make a request from food com2 bar calm and bar.com actually has the course headers you can make it send the proper
• 20:30 - 21:00 cookies on bar comm up to that server and you can't access those yourself but you can potentially compromise logged in users and really this just hasn't been explored people have played around with cores it's fairly well designed but it's still very much new territory and it's something that I really encourage you to look into and play around with a little bit you're gonna see some examples in your course work but there are a lot of
• 21:00 - 21:30 things that just haven't been touched yet so I recommend that you just go and explore maybe a little bit later in the course as you get more advanced as a breaker [Music] now let's talk about sea surface acts these are one of my all-time favorite vulnerabilities it's simple when you find it everywhere usually if you find one on an app you're gonna find it systemic you're gonna find that they have no prevention against it and this isn't an uncommon thing I would say probably one in five or six apps that I
• 21:30 - 22:00 test fall prey to sea surf at least in one case generally more than that [Music] so what is it cross-site request forgery is basically when an attacker can get a victim to go to a page that they control and then it submits data to some target site as the victim it's excruciatingly ly common and it's brutal the canonical example is a bank transfer site here we have this form that allows transfers
• 22:00 - 22:30 from one account to another and it's very simple you have a post up to some level you have the two variable which has your destination account you have the amount that's being set and then you have a submit button that's it [Music] so when the server gets such a request how can it know that it actually came from the real site that they actually went to that forum and entered the data you have the referrer headers as I mentioned before this come up in the
• 22:30 - 23:00 HTTP request but they're unreliable at best at worst they're forged here we can see an actual exploit that will transfer money if the users logged in it's again a very simple form as two hidden inputs and a mountain - and it transfers from one account whatever account the user is logged into to account number one six two five transfers a million dollars into that account and that happens instantly
• 23:00 - 23:30 because when the body loads it automatically submits that form so how does the server tell that this request is any different from a normal request the user would make even though the user had nothing to do with this transfer that's the big question the see surf and the answer is they can't [Music] so clearly we need to give the server a way to know where the request originated from did it originate on its page or
• 23:30 - 24:00 somewhere else the way that this is traditionally done and it's traditional because it works [Music] is to mitigate the bug through the use of sea surf tokens basically all you have to do is just generate a random token tie it to the user session and then embed it in each form that you generate every single form that you generate is going to send up an additional input of that sea surf Cokin [Music]
• 24:00 - 24:30 here you can see a form that actually contains that see surf token it's a 32 nibble token plenty of randomness so you're never going to guess it and it's just set up as a hidden input whenever the server gets a post request any post requests should always check to see that the C surf coke in this present and that it actually matches the token that's in the user session the interesting thing here is that this all hinges on posts being the only time that
• 24:30 - 25:00 you're changing state yet requests should only ever give you data they should never actually change data as you're gonna find out if you ever just run an automatic scanner against an application applications change state with get all the time this is something that is very pervasive in the web development community despite it being a code smell everywhere it's something you're going to find all the time and it is really just quite nasty
• 25:00 - 25:30 so if they're doing that even if they're checking see surf tokens on every post if they're changing state inside of get requests they're automatically broken it's just not going to work out very well for them I've seen a number of apps do this now where they implement dynamic C surf proof forms as I like to call them basically instead of every form having to have a C surf token baked into it on the server which it requires you
• 25:30 - 26:00 to put it into the form it requires you to generate these pages anew every time on the server you can't cache them except per user because they do have a user specific token in them instead what they would do is they would load up a file from the server we'll call it C surf Jas and they would load this into the page which would really just add a variable onto the page or into the pages scope with the C surf dokkan and then it will walk over all the forms on the page
• 26:00 - 26:30 and add the C surf token to them which seems like a great solution you're adding the C surf coke in there but if you have a C surf token just sitting in a JavaScript file what's to stop an attacker from just adding that to their exploit if your if you give away the C surf token in some way [Music] you've automatically broken the protection so as an attacker this is a really handy thing to have and I can think of at least three or four cases at
• 26:30 - 27:00 this point of seeing the sort of dynamic sea surf protection in action every time it's just as broken [Music] so it's too quick wrap up [Music] to review cookie domain scoping is often a source of trouble as we've seen there three real core rules but nobody gets it right so what I encourage you to do is just open up verapaz before and just
• 27:00 - 27:30 start browsing the web and if you log into a couple pages I bet you that you'll see some that are scoped to sort of weird domains you know they won't use a specific authorization sub domain despite that they're running a bunch of different apps on one one domain things like that that sort of scoping can often mess you up the same origin policy is strict but it's very complex in a lot of ways and what that does is it makes things very
• 27:30 - 28:00 nice for a developer in that you can actually fine-tune the way that things work but it also makes it difficult to know how the application is being secured and course really mixes that up as do the ways to loose an SOP and then cross-site request forgery is when an attacker tricks a victim into go into a page which triggers requests on another site always use C surf tokens if you don't see a c surf talk in a form even
• 28:00 - 28:30 if it's a form that doesn't really do anything that should be a finding no matter what may be a low severity but generally for me C surfs are at least a medium often a high or a critical depending on what the business impact is well that wraps it up for this session until next time happy breaking