Edits made

Articles/st27_ExploitWeekIntro.md

@@ -5,9 +5,11 @@ will also get the opportunity to put the theory into practice in the
 lab and do some hacking.
 
 > This is a pretty hardcore week, we will be looking at (and
-> performing) real exploits of vulnerable services.  However, you won't
-> need any specialist tools or knowledge, just a web browser and a bit
-> of thought. [LD comment: Perhaps an additional comment such as: 'Some of this may be challenging to digest as you navigate through the material; however, rest assured, we'll explore the practical side of this content in the lab session]()
+> performing) real exploits of vulnerable services.  However, you
+> won't need any specialist tools or knowledge, just a web browser and
+> a bit of thought.  Some of this may be challenging to digest as you
+> navigate through the material; however, rest assured, we'll explore
+> the practical side of this content in the lab session
 
 ## Intro to the Exploits
 
@@ -27,21 +29,26 @@ and methods that web site developers can use to protect against them.
 
 ## Why these Exploits Happen
 
-As we have moved from static web pages to the 'wonders' of Web2.0 [LD comment: A definition would be helpful here](), we
-have needed ways of getting users to interact with a website. While
-this has let us do many amazing things, it has also been the primary
-cause of insecurity in web apps (and just about any other type of
-application).
+As we have moved from static web pages to the 'wonders' of Web2.0,
+with its responsive content and use of dynamic technologes such as
+javascript, we have needed ways of getting users to interact with a
+website. While this has let us do many amazing things, it has also
+been the primary cause of insecurity in web apps (and just about any
+other type of application).
 
 The main problem here is that allowing users a way of arbitrarily
 adding input, means that they will do unexpected things. Therefore we
 get to **RULE #1: NEVER trust user input**.  This is the root cause of
 many web based (and non web based) security flaws, and occurs in
-topics such as: [LD comment: Some brief definitions for 'Form Validation', 'Buffer overflows' and 'Remote Command Execution' would aid understanding.]()
-
--   Form Validation
--   Buffer overflows
--   Remote Command Execution
+topics such as: 
+
+-   Form Validation: Checking the information that the users have
+    submited to programs, to ensure that no malicious code can be
+    executed
+-   Buffer overflows: A prgramming flaw where we are able to overwrite
+    a programs memory, changing its behavour.
+-   Remote Command Execution: Where a system allows remote users to
+    run commands on a server.
 -   Users Breaking our lovely program by being idiots (**RULE #2: The second
     you make something "Idiot proof", they will release an upgraded
     version of Idiot**)

Articles/st28_XSS.md

@@ -131,7 +131,7 @@ This would use the payload: [LD comment: 'payload'?]()
 
 
 Consider the [XSS Example](http://172.18.0.1/reflected_xss_get.php)
-from before. We know the form takes a GET [LD comment: What's GET?]() request, then echoes it's
+from before. We know the form takes a GET request , then echoes it's
 value back to the user. Consider what would happen if we could trick
 the user into clicking the following URL.
 

Articles/st29_Sqli.md

@@ -140,7 +140,7 @@ SELECT * FROM user WHERE username="Evil"#
 
 ### Logical Comparisons
 
-Now the trick here is to consider how SQL parses [LD comment: 'parses'?]() any logical statements in the query.
+Now the trick here is to consider how SQL processes any logical statements in the query.
 
   - x AND y:  Return all rows where BOTH x AND y are true
   - x OR y:  Return all rows where EITHER x OR y are true

GLOSSARY.md

@@ -48,3 +48,29 @@
 - Social Engineering
 
 
+- Web 2.0 
+
+  The New Web, that emerged in the early 2000's.  where technolgies
+  such as Javascript allowed us to move from purely static HTML sites
+  to those with responsive and interteractive content.
+
+
+- GET Requests
+
+  A method of sending data to a web server.  GET requests are encoded
+as part of the URL (do a Google search and look at the URL for a good
+example of this). The part appended to the string containing the
+parameters is known as the **query string**.
+
+  You can see GET requests in action on Google, after making a search
+  you will notice a lof of information in the URL, this represents the
+  search terms that the server is processing.
+
+- POST Requests
+
+POST requests are encoded inside the request **body**. This means that
+the request itself is only visible by inspecting the headers, rather
+than as part of the URL. This makes it slightly harder to modify the
+request, as we cannot just manipulate the URL, and would need to use a
+tool to add the parameters to the request body. We will discuss
+manually sending requests to the server in the next step.