Joe DiNicola
Spring 2021
MP*: 2 Credits
Summary:
1.b) Refreshing on web fundamentals
1.a) Refreshing on Linux Fundamentals
2.) Learning to use Burp Suite software(mini course)
3.) OWASP Juice Shop CTF(mini course)
5.) Web Fundamentals path way(Course)
Web Fundamentals Course:
Section 1: Web Fundamentals
- Introductory Networks
- OSI Model:
- Application
- Presentation
- Session
- Transport
- Network
- Datalink
- Physical
- Data Encapsulation
- basis of how data is transmitted across a network

- TCP/IP Model
- Commands:
- ping
- traceroute
- dig
- WHOIS
- etc...
- Web Fundamentals
- Introduction to Django
- Python-based web framework
- Secure
- Strong against sql-attacks with proper configuration
- Queries use parameterization
Section 2: Security Tools
- Burp Suite
- Proxy
- Tools:
- Intruder
- Comparer
- Decoder
- Etc

- Intro to OWASP ZAP
- Another proxy tool

- Pro's:
- No paid version
- tools are not throttled
- Brute force attacks complete in fraction of time as BurpSuite student Version
- same tools as burp
- Site Scan and mapping
- Paid version required for Burp.

Section 3: Vulnerabilities
- LFI
- Local File Inclusion
- Including a file request from the server in the url in hopes of retrieving sensitive information
- ex: .com/?file=robots.txt
- can be used to expose information from /etc/passwd which stores user account info across the system and much more.
- With passwd.txt available, we can use that information to view the users we've discovered and use the same trick to view their id_rsa key in their .ssh folder.
- From there we have remote access to their account without knowing their password.
- XXE
- Sites use xml code to process data
- Using malicious xml code to retrieve sensitive information from the system
- ex:
- <?xml version="1.0"?>
<!DOCTYPE root [<!ENTITY read SYSTEM 'file:///etc/passwd'>]>
<root>&read;</root>
- DOCTYPE is where we define the structure of the xml code that follows.
- We will replace read with a request for the file path "///etc/passwd"
- Like we learned in the LFI Section, "passwd.txt" contains sensitive account information for users on the system.
- With the passwd file we can use XXE attacks to once again retrieve the id_rsa key of whatever user we choose in the passwd file.
- Cross-Site Scripting
- Types:
- Reflected
- Malicious payload is used in the request and response to a website(non-persistent).


- Stored
- Un-sanitized user input is stored in a sites database(persistent).
- All users of a site can be affected.


- DOM-Based XSS
- Malicious payload is executed only upon execution.

- Uses:
- Key logging
- Can use a key logger made in a language like javascript to report a key input event for a user and ugload it to some sort of log page to view a victims typing
- ex:
- viewing the user and password a user types in.
- Filter Evasion
- Sites can use things such as filters to help protect from XSS attacks
- However filters can be side stepped.
- Protection:
- Escaping user input
- a function from flask that changes characters like "<" and other dangerous characters to HTML-safe sequences.
- validating User Input
- frameworks like Django allow you to validate input by making sure the input is what should be expected.
- ex: making sure input is a number when a number is expected by parsing and proceeding to work with that input as if its a number. If an error occurs, you can return a Validation Error.
- Sanitizing user input can be used but should not be the only layer of defense.
- Sanitizing turns user input into an acceptable(non-malicious form)
- Obscure Website Vulnerabilities
- SSTI:
- Server Side Template Injections allow attackers to take advantage of template injections
- ex:
- {{ ''.__class__.__mro__[2].__subclasses__()[40]()(/etc/passwd).read()}}
- which should return(if vulnerable) the passwd file
- CSRF:
- Cross Site Request Forgery is tricking the victim to click a link to a website created by the attacker
- link involves some sort of request that looks legitimate in the webservers eyes(victim assumingly holds some sort of cookie for this site)
- useful for phishing attacks and such.
- JWT
- Json Web Tokens are used for create access tokens for an application and are very popular.
- If done incorrectly though, can become a vulnerability.
- Structure:
-
- Header.Payload.Signiture
- Header
- Token type
- algorithm used
- Payload
- contains the claims of the token
- Registered claims:
- issuer, expiration time, subject, audience etc.
- Public claims:
- defined by who is using the token
- Private claims:
- custom claims to share info between parties.
- Signature
- Encryption of header and encoded payload, and the secret(key), with encryption in header.
- Vulnerabilities lie in improper implementation of JWT
- If vulnerable, we can alter the alg declaration in the header and change it to "None" or another valid alg which is vulnerable
- "None" allows us to alter the payload without requiring a signature.
Outcomes:
- Learned much more than I ever would've imagined in Web Vulnerabilities.
- Landed a Co-Op with Lockheed Martin mainly due to what I learned during my MP*
Sources: