Web Application Penetration Testing – Case Study – Problem statement
Penetration Testing
Consider the following scenario:
1.Website: https://www.cmsmadesimple.org/
2.Download the copy of CMS from the above website and install/configure it in Apache HTTP Server in any of the following pre-configured setup:
a.XAMPP -https://www.apachefriends.org/download.html
b.WAMP -http://www.wampserver.com/en/
c.UWAMP -https://www.uwamp.com/en/
3.Install Documentation-https://docs.cmsmadesimple.org/installation/installing
To Do: 1.Do penetration testing and generate the following report as per the guidelines in point 3 and 4:
a.Summary of penetration testing.
b.Each step and the information collected during penetration testing.
c.All the vulnerabilities and risks discovered.
d.Possible security fix.
e.Feedback for future security.
2.You may want to follow following steps while doing penetration testing:
a.Information Gathering
i.”Find the version and type of a running web server to determine known vulnerabilities and the appropriate exploits. Using “”HTTP header field ordering”” and “”Malformed requests test””.”
ii.Analyse robots.txt and identify <META> Tags from website.
iii.Find applications hosted in the webserver (Virtual hosts/Subdomain)
iv.Find sensitive information from webpage comments and Metadata on source code.
v. Identify from hidden fields, parameters, methods HTTP header analysis
vi.Map the target application and understand the principal workflows.
vii.Find the type of web application framework/CMS from HTTP headers, Cookies, Source code, Specific files and folders.
viii.Identify the web application and version to determine known vulnerabilities and the appropriate exploits.
ix.Identify application architecture including Web language, WAF, Reverse proxy, Application Server, Backend Database
b.Configuration and Deploy Management Testing
i.Understand the infrastructure elements interactions, config management for software, backend DB server, WebDAV, FTP in order to identify known vulnerabilities.
ii.Identify default installation file/directory, Handle Server errors (40*,50*), Minimal Privilege, Software logging.
iii.Find important file, information (.asa , .inc , .sql ,zip, tar, pdf, txt, etc)
iv.Check JS source code, comments, cache file, backup file (.old, .bak, .inc, .src) and guessing of filename
v.Directory and file enumeration, comments and links in source (/admin, /administrator, /backoffice, /backend, etc), alternative server port (Tomcat/8080)
vi.curl -s -D-https://domain.com/ | grep Strict”
vii.Analyse the permissions allowed from the policy files (crossdomain.xml/clientaccesspolicy.xml) and allow-access-from.
c.Identity Management Testing
i.Validate the system roles defined within the application by creating permission matrix. ii.”Verify that the identity requirements for user registration are aligned with business and security requirements:”
iii.”Determine which roles are able to provision users and what sort of accounts they can provision.”
iv.Generic login error statement check, return codes/parameter values, enumerate all possible valid userids (Login system, Forgot password)
v.Guest and Training accounts are useful ways to acquaint potential users with system functionality prior to them completing the authorisation process required for access. Evaluate consistency between access policy and guest/training account access permissions. vi.Verify the identity requirements for user registration align with business/security requirements. Validate the registration process.
d.Authentication Testing
i.Check referrer whether its HTTP or HTTPs. Sending data through HTTP and HTTPS. ii.Testing for default credentials of common applications, Testing for default password of new accounts.
iii.”Evaluate the account lockout mechanism’s ability to mitigate brute force password guessing. Evaluate the unlock mechanism’s resistance to unauthorized account unlocking.” iv.Force browsing (/admin/main.php, /page.asp?authenticated=yes), Parameter Modification, Session ID prediction, SQL Injection
v.Look for passwords being stored in a cookie. Examine the cookies stored by the application. Verify that the credentials arenot stored in clear text, but are hashed. Autocompleted=off?
vi.Check browser history issue by clicking “Back” button after logging out. Check browser cache issue from HTTP response headers (Cache-Control: nocache)
vii.”Determine the resistance of the application against brute force password guessing using available password dictionaries by evaluating the length, complexity, reuse and aging requirements of passwords.”
viii.Test password reset (Display old password in plain-text?, Send via email?, Random token on confirmation email ?), Test password change (Need old password?), CSRF vulnerability ? ix.Understand the primary mechanism and Identify other channels (Mobile App, Call center, SSO)
e.Session Management Testing
i.The application doesn’t renew the cookie after asuccessfully user authentication. ii.Encryption & Reuse of session Tokens vulnerabilities, Send sessionID with GET method ? iii.URL analysis, Direct access to functions without any token.
iv.Check reuse session after logout both server-side and SSO.
v.Check session timeout, after the timeout has passed, all session tokens should be destroyed or be unusable.
vi.The application uses the same session variable for more than one purpose. An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another.
f.Data Validation Testing
i.Identify database version, Single quote, Information schema, Read/Write file. 3.Penetration Testing Report should capture the data in following format:
4.You should list/rate each vulnerability under following single or multiple categories with additional information:
a.Skills required by hacker
b.Possible Motive
c.Resources/Infrastructure required by hacker
d.Easy of Discovery
e.Ease of Exploit
f.Intrusion Detection
g.Possible chances of Loss of Integrity
h.Possible chances of Loss of Availability
i.Possible chances of Financial damage
j.Possible chances of Reputation damage
k.Possible chances of Non-Compliance
l.Possible chances of Privacy violation
The post Web Application Penetration Testing appeared first on My Assignment Online.