Scribd
Upload
200 views2 pages

Hacker 101

The document provides guidelines for documenting software vulnerabilities. It recommends including the title, severity, description, reproduction steps, impact, mitigation, and affected assets for each vulnerability. It also discusses request headers like host, accept, cookie, and refer when making web requests. It explains cookie security based on domain and subdomain, and important cookie flags like secure and httponly. It notes parsers may differ between browsers and filters, potentially leading to vulnerabilities. Content sniffing determines a resource's type based on its content rather than its headers.

Uploaded by

Emiliano Larrea
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
200 views2 pages

Hacker 101

The document provides guidelines for documenting software vulnerabilities. It recommends including the title, severity, description, reproduction steps, impact, mitigation, and affected assets for each vulnerability. It also discusses request headers like host, accept, cookie, and refer when making web requests. It explains cookie security based on domain and subdomain, and important cookie flags like secure and httponly. It notes parsers may differ between browsers and filters, potentially leading to vulnerabilities. Content sniffing determines a resource's type based on its content rather than its headers.

Uploaded by

Emiliano Larrea
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Hacker101:

For each vulnerability, should include:


• Title:
• Severity:
o Informational: issue has no real impact, but it could in the future.
o Low: The business impact is minimal.
o Medium: Potential to cause harm to users, bur not revealing critical data.
o High: Potential to reveal user data or aids in exploitation of other
vulnerabilities.
o Critical: High risk of personal/confidential data exposure, general system
compromise, and other severe impacts to the business.
• Description:
• Reproduction Steps: Brief description of how to reproduce the bug, preferably with
a small proof of concept.
• Impact: What can be done with the vulnerability?
• Mitigation: How is it fixed?
• Affected assets: generally a list of affected URL’s
The web in Depth:
Request Headers:
• Host:
• Accept: indicates what mime types are accepted by the client (json, xml)
• Cookie
• Refer: Page leading to this request (this is not passes to other servers when using
HTTPS on the origin)
• Authorization: Used for basic auth pages.
Cookie Security:
• Cookies added for a domain can be read by any subdomain of it.
• Cookies added for a subdomain can only be read in that subdomain and its
subdomains.
• A subdomain can set cookies for its own subdomains and parent, but it can’t set
cookies for sibling domains.
Cookies flags:
There are two important flags to know for cookies:
o Secure: the cookie will only be accessible to HTTPS pages.
o HTTPOnly: the cookie cannot be read by JS.
The server indicates these flags in the Set-Cookie header that passes them in the first
place.
Parsing:
HTML should be parsed according to the relevant spec, generally HTML5 now. But
when we’re talking about security, it’s often not just parsed by your browser, but
also Web-Application Firewalls and other filters. Wherever there’s a discrepancy in
how these two items parse things, there’s probably a vulnerability.
A bad XSS filter on the web application may not see that as a script tag due to it
being a ‘script/xss’ tag.
Content Sniffing: (10 min https://www.youtube.com/watch?
v=DWBUQiaN5ZM&list=PLxhvVyxYRviZsAKXZEbmfsVMZp3s0KaVE&index=2)

You might also like