It took me about an hour to get through the 10 minute video because I had to take so many notes on the topics covered. It felt like there were so many things that never got covered in the slides before they were introduced in the video. We went from barely touching JavaScript to crafting these detailed payloads.
Hi!
As far as I remember, the DOM part was pretty self explained. However, if you feel like you need to cover more in this topic, in internet you can find useful resources. For example What is DOM-based XSS (cross-site scripting)? Tutorial & Examples | Web Security Academy
It wasn’t so much the concept of DOM based XSS but other topics brought up in the video. For example, “Another way to shrink our code is to build an SVG element on the fly.” Ummm, build a what? I guess I’m just hoping that I didn’t mess up by doing this course as a total web app beginner.
This course is for beginners, a lot of INE courses teach you new topics in the videos and sometimes they assume that you know the stuff explained. My suggestion is to make your own research when you feel like that topic confuse you 
.
Don’t hesitate to search on the internet even basic topics, it’s normal! I always search for basic things even after like 4 years 
.
1 Like
That makes sense. I usually do that too. Sometimes it helps, sometimes it doesn’t. For example. In Section 4.5.2 we’re talking about XSS attacks. They’re talking about DOM letting us bypass SOP. They say, “We use the following trick”
I’m sitting here wondering what in the world that is. They briefly talk about the code in the next slide but it still leaves me very lost.
So, as well as the visual representation of a web page you see in your browser, web pages are represented (“logically”) in memory as a hierarchical structure, called the Document Object Model (DOM).
Scripts can query the DOM programmatically, to get information on the elements within it.
The code snippet presented in the slides is doing a couple of things:
The HTML bit at the bottom: creates an iFrame element within the current page, which points at the URL: “/path1/index.php” - the result of this that the page at /path2/ now has a frame embedded within it which points to /path1/.
The JavaScript bit at the top: when the page loads, this bit of code is triggered - it queries the DOM and cycles through the all frame objects within it, looking for ones whose “location” URL contains the characters “/path1/”. This will find the iFrame we just created (because its “location” property contains “/path1” and parse the cookie value from it.
The purpose of this snippet is to demonstrate that “Cookie Path” in of itself does not enforce security; even if a page has its Cookie Path set to “/path1/”, you can still query that page’s cookie value from a page on “/path2/” via the DOM, provided that page is capable of housing an iFrame which points to “/path1/”.
Hope that doesn’t confuse things even more… brain is a bit fried as I’ve been doing the labs in Ch.14 for too long today!
1 Like
That doesn’t confuse things more. Thank you for taking the time to explain that, I appreciate it!
no problem, glad it helps.
If it makes you feel any better, I spent about 3 hours recently on one of the 10 minute videos in Ch.14 - I was really struggling with some of the concepts, so spent a lot of time doing extra research, took loads of notes and screenshots etc. Knocked my confidence and messed up my schedule, but I ended up with a much better grasp of the subject and a solid set of notes to refer back to. As for the amount of code/script/web dev stuff in the course - it doesn’t go too deep into that side of things. For this course, I’d say its probably more important to be able to read through an existing exploit (e.g. from Exploit-DB) and understand enough of how it works to be able to modify it to suit your needs, rather than writing scripts from scratch.
1 Like