文档中心 > Miravia Open Platform

Miravia - Security Testing Standard

更新时间:2022/12/01 访问次数:568

1. Purpose

This document aims to summarize the security testing process. The entire process consists of the following:

a. Planning and Scoping

b. Threat Modeling

c. Announcement

d. Testing

e. Post-Testing

f. Reporting

Our testing methodology is based on the best practices from OWASP (www.owasp.org) and SANS (www.sans.org).

If you have any comments, feedback, queries, please contact shivendra.saxena@lazada.com

 

2. Planning and Scoping

2.1 Determine the platform to be tested on - Testing, UAT, Production.

2.2 Determine the URL(s) and hostname(s) to be tested.

2.3 Determine the application modules/functions to be tested.

2.4 Request for testing accounts - mandatory 2 testing accounts for each role.

2.5 Request for documentation.

2.6 Determine the start date/time and end date/time.

2.7 Identify any testing limitations - e.g. Black-box testing without source code, WAF, etc.

 

There will be no intrusive testing and efforts would be made to minimize any disruptions (especially while testing on the production environment). ISV would be notified immediately, should there be a payload which causes material disruption to the system.

 

3. Threat Modeling

3.1 Risk Assessment tells us how much damage an attack could cause but it is also very important to understand how the application/system might be attacked.

 

3.2 Needs for Threat Modeling

1. To understand what the attack goals are.

2. To understand who the attackers are.

3. To understand what attacks are likely to occur.

 

3.3 Steps in Threat Modeling

1. Identify and document critical assets.

2. Identify and document each component in the system.

3. Identify and document possible points of attack (i.e. attack tree).

4. Identify and document threats that pertain each possible attack point.

5. Identify and document the category and priority of the attack.

6. Identify and document the mitigation solutions/controls.

 

4. Announcement

Before the start of any security testing, the security team will send out an email announcement to the ISV. The announcement email will consist of the following information:

a. Target(s) to be tested (ISV application)

b. Attacking source IP address (Miravia IP address)

c. Start date/time and End date/time (Singapore time zone, unless specified otherwise)

 

       Kindly ensure that the Miravia IP address is whitelisted during the entire duration of the testing.

 

5. Information Gathering

5.1 Manually explore the site

5.2 Spider/crawl the site for hidden content and using the files listing to assist the crawl.

5.3 Check the webserver metafiles for information leakage files such as robots.txt, sitemap.xml.

5.4 Use Google for publicly accessible URLs.

5.5 Check what web application framework is used - PHP zend framework, J2EE, etc.

5.6 Perform web application fingerprinting.

5.7 Identify technologies used.

5.8 Identify application entry points.

5.9 Identify client-side code.

5.10 Identify multiple user interfaces - web, mobile web, mobile app, web services.

5.11 Identify all services and ports.

 

6. Configuration Management

6.1 Check for hidden URLs and administrative URLs.

6.2 Check for old, backup and unreferenced files.

6.3 Check for Cross Site Tracing (XST) 6.4 Check for sensitive data in client-side code (e.g. API keys, credentials).

 

7. Secure Transmission

7.1 Check for weak SSL / TLS versions support, ciphers suites support, key length.

7.2 Check for digital certificate validity (duration, signature, cn).

7.3 Check for sensitive data and credential delivered over HTTPs.

7.4 Check if login form is using HTTP POST over HTTPS.

7.5 Check that session tokens are only delivered over HTTPS.

 

8. Authentication

8.1 Test for authentication bypass.

8.2 Test if credentials are transported over an encrypted channel.

8.3 Test “remember me” functionality that stores clear-text password in browser.

8.4 Test password reset, change and/or recovery. 8.5 Test CAPTCHA (if present).

8.6 Test multi-factor authentication (if present).

8.7 Test for logout functionality presence.

8.8 Test for weak security question/answer.

 

9. Session Management

9.1 Check how session management is handled (eg, tokens in cookies, tokens in URL).

9.2 Check session tokens for cookie flags (httpOnly and secure).

9.3 Check session cookie scope (path and domain).

9.4 Check session cookie duration (expires and max-age).

9.5 Check session termination after a maximum lifetime.

9.6 Check session termination after relative timeout.

9.7 Check session termination after logout.

9.8 Test to see if users can have multiple simultaneous sessions.

9.9 Test session cookies for randomness and uniqueness.

9.10 Confirm that new session tokens are issued on successful login and role change.

9.11 Test for consistent session management across applications with shared session management.

9.12 Test for session puzzling.

9.13 Test for CSRF and clickjacking.

 

10. Authorization

10.1 Test for path traversal.

10.2 Test for vertical Access control problems (a.k.a. Privilege Escalation).

10.3 Test for horizontal Access control problems (between two users at the same privilege level).

10.4 Test for missing authorisation.

10.5 Test for Insecure Direct Object References.

 

11. Data Validation

11.1 Test for Cross Site Scripting.

11.2 Test for SQL Injection.

11.3 Test for LDAP Injection.

11.4 Test for XML Injection.

11.5 Test for XPath Injection.

11.6 Test for Code Injection.

11.7 Test for Command Injection.

11.8 Test for HTTP Splitting/Smuggling.

11.9 Test for HTTP Verb Tampering.

11.10 Test for Open Redirection.

11.11 Test for Local File Inclusion.

11.12 Test for Remote File Inclusion.

 

12. Business Logic

12.1 Test for feature misuse.

12.2 Test for integrity of data.

12.3 Test for the Circumvention of Work Flows.

12.4 Test Upload of Unexpected File Types.

 

13. Cryptography

13.1 Verify if sensitive data is encrypted using public key encryption.

13.2 Check for weak algorithms in encrypting sensitive data (i.e, ROT13, Base64, DES, 3DES).

13.3 Check for cryptographically secure randomness in encryption function.

 

14. File Uploads

14.1 Test that file size limits, upload frequency and total file counts are defined and are enforced.

14.2 Test that file contents match the defined file type.

14.3 Test that unsafe filenames are sanitised.

14.4 Test that uploaded sensitive files are stored outsides of web root directory.

14.5 Test that files and other sensitive media are integrated with the authentication and authorisation schemas.

 

15. Reporting

5.1 All findings will be reported on the Datamoat platform. ISV will get a notification.

FAQ

关于此文档暂时还没有FAQ
返回
顶部