Ethical Hacking - C701 CEH Certified Ethical Hacker Practice Exams, Fourth Edition 2/2

In nmap, the http-methods script can be used to test for potentially risky http options supported by a target. Which of the following methods would be considered risky per the script?

CONNECT The http-methods script usage syntax is nmap --script http-methods <target>, where <target> is the IP of the system you're after. Per nmap's support pages (https://nmap.org/nsedoc/scripts/http-methods.html), this script "finds out what options are supported by an HTTP server by sending an OPTIONS request and lists potentially risky methods. It tests those methods not mentioned in the OPTIONS headers individually and sees if they are implemented. Any output other than 501/405 suggests that the method is not in the range 400 to 600. If the response falls under that range then it is compared to the response from a randomly generated method. In this script, 'potentially risky' methods are anything except GET, HEAD, POST, and OPTIONS. If the script reports potentially risky methods, they may not all be security risks, but you should check to make sure." You can also use additional parameters, such as url-path, to further hone your results. For example, output from the preceding syntax showing PUT as a risky method might look like this:

A web application developer wants to test a new application for security flaws. Which of the following is a method of testing input variations by using randomly generated invalid input in an attempt to crash the program,?

Fuzzing Even if you didn't know what "fuzzing" meant, you probably could've whittled this down by eliminating the known wrong answers. Per OWASP (https://www.owasp.org/index.php/Fuzzing), "Fuzz testing or fuzzing is a Black Box software testing technique, which basically consists in finding implementation bugs using malformed/semi-malformed data injection in an automated fashion." In other words, fuzzing sends tons of weird inputs into fields to see what the application will do.

OWASP, an international organization focused on improving the security of software, products a list called OWASP Top 10 most critical web application security risks for web applications. Which item is the primary concern on the list?

Injection Flaws know you're thinking there is no way something this specific and picky will be on the exam, but I promise you will see something like this on your exam (not verbatim, of course, but you get my drift). The most current version (as of this writing) of OWASP's Top 10 Most Critical Web Application Security Risks can be found on the OWASP site (https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project), and ECC loves it. If nothing else, memorize the top five items on the list: A1 - Injection Flaws Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. (Position on previous/last year's list: #1.) A2 - Broken Authentication and Session Management Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities. (Position on previous/last year's list: #2.) A3 - Sensitive Data Exposure Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection, such as encryption at rest or in transit, as well as special precautions when exchanged with the browser. (Position on previous/last year's list: #6.) A4 - XML External Entities (XXE) A new addition for the 2017 list. Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies, or integrations. By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks. A5 - Broken Access Control A new addition for the 2017 list. Exploitation of access control is a core skill of attackers. SAST and DAST tools can detect the absence of access control but cannot verify if it is functional when it is present. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks. Access control weaknesses are common due to the lack of automated detection and the lack of effective functional testing by application developers. Access control detection is not typically amenable to automated static or dynamic testing. Manual testing is the best way to detect missing or ineffective access control, including HTTP method (GET vs. PUT and so on), controller, direct object references, and so on.