1. For whom are the security assessments of Web Security Scan?
The penetration tests and security scans offered by Web Security Scan are suitable for anybody who wants to know the current security status of their web application or underlying IT-infrastructure. From SME's to large (public and private) organisations. Most requests for security assessments are initiated by website owners, product owners, (project) managers, system administrators, web masters, developers and security professionals.
2. What is the difference between Web Security Scan and other services?
Web Security Scan combines manual and automated security tests. We analyze the behavior and structure of your web application and underlying systems, to perform the best-suited security checks and produce the best results possible. Many other service providers merely use fully automated security software (so-called point-and-shoot tools), which make crucial assumptions about the web application itself, often resulting in application functionalities checked the wrong way or not at all.
3. Is my web application 100% secure after a security scan?
It is a misunderstanding that systems or web applications can be 100% secure. Even after performing the most extensive and advanced security tests (manual or automatic) and taking extra security measures, a system or web application potentially still stays vulnerable. A web application has to deal with a great number of potential vulnerabilities and threats. Web Security Scan helps you to minimize the chance of a hacker successfully exploiting your web application.
4. What are the advantages of manual testing methods?
At Web Security Scan, we are skilled in executing automated security scans, which have certain advantages over manual testing. However, automated scans inherently come with limitations, since it cannot capture all areas of web application security. While not all testing methods can be automated, automated tests also leave in-house security employees behind with interpreting results, sometimes missing out or not understanding these results. Our certified security experts understand (automated) test results and provide support in fixing found vulnerabilities and issues. Other limitations of automated testing are:
- Differences between web applications: an automated scan tool is typically able to find many vulnerabilities in popular products (such as Drupal, WordPress, Magento), since a vulnerability would have a great impact for all its users. Custom products are less likely to have automated scan tools built for them that are able to find existing vulnerabilities in the product.
- Syntax and semantics: automated scan tools are able to understand the syntax, or technical meaning, of every vulnerability that is found, but not its semantics, or rather the importance of such a vulnerability. For example, in a shopping cart, being able to modify the delivery date of the product to a date in the past is relatively harmless, but being able to modify the price of a product is a serious security flaw. An automated scan tool is not able to interpret the difference in semantics.
- Improvisation: The use of non-standard mechanisms of communication in a website is typically a hint at a possible security flaw. However, automated scans will not be able to improvise exploiting these hints, nor be able to circumvent partially effective security measures, such as those put in place not definitively solving the problem, but only blocking the scan in question.
- Intuition: An automated scan’s way of operating is largely to attempt every attack against every part of the website, a so-called brute force way of scanning. However, some vulnerabilities require intuition and manual inspection in order to be discovered. Some examples include attacks where input needs to be crafted in a specific way, or where specific input needs to be inserted in specific sequence.
5. Why is my application/system a target?
Every system or application on the Internet is a potential target. The Internet is being scanned by hackers 24/7 to find vulnerable systems and applications, regardless of the size of your organization. A brief overview of ways in which hackers can abuse systems:
- Data Harvesting – a direct attack to steal valuable customer and company information. For example: credit card numbers, login credentials, email addresses and social security numbers.
- Spam – sending out millions of unsolicited emails. Spammers can cause severe damage, use all your bandwidth, cause a bad reputation for your organization or disrupt your complete email traffic by becoming blacklisted.
- Storage – illegal software, music, video and images take costly bandwidth, but could also result in having your system being taken offline by the authorities for further investigation.
- Distribution of malware – your application will be used to infect visitors with malware. When infected, hackers have total control over the customer's computer. This can cause blacklisting by search engines like Google and harm the reputation of your organization.
- Jump point – your system will be used to hack other systems. The attack will lead back to your system, having consequences for you and your organization.
- Defacement – your website page is modified by hackers so visitors do not get to see your own website. Often hackers turn your page into a "Hacked by X" designed website.
6. What scan frequency should I use?
It is important to check your security after changes and updates have taken place. The smallest change in code or configuration could expose your application and introduce new vulnerabilities. Even if you do not update your application often, it is still important to check your security regularly. New vulnerabilities, as well as new hacking techniques are found, developed and published on the Internet every day. Web Security Scan always uses up to date software to detect the most recent vulnerabilities. We can help determine the appropriate scan frequency for you.
7. Does Web Security Scan offer support to fix security issues?
Yes, we gladly offer support to fix vulnerabilities in your application. Web Security Scan is part of DongIT, so besides security assessments and penetration testing, DongIT develops secure web applications based on the most recent open source software and techniques. For more information about the possibilities, contact us directly.
8. Does Web Security Scan offer support for taking extra security measures?
Yes, we can offer extra support and advice to help you take intensified security measures on application-, network- and system-level. For example by monitoring your web services and systems, installation of a Web Application Firewall (WAF), application of server hardening and source code analysis.
9. What are the advantages of using the scan sensor?
One of the tools we use is Acunetix AcuSensor Technology, which is a security technology that allows you to identify more vulnerabilities than a traditional Web Application Scanner, whilst generating less false positives. In addition, it reports debug information and indicates exactly where in your code the vulnerability is.
The increased accuracy is achieved by combining black box scanning techniques with feedback from sensors placed non-destructively inside the source code. Black box scanning does not know how the application reacts and source code analyzers do not understand how the application will behave while it is being attacked. Therefore, the combination of these techniques will achieve more relevant results than using source code analyzers and black box scanning independently. However, there are more advantages to using the scan sensor:
- Allows you to locate and fix the vulnerabilities faster because of the ability to provide more information about vulnerabilities, such as source code line number, stack trace and affected SQL queries.
- Significantly reduces false positives when scanning a website because, internally, the behavior of the web application is better understood.
- Can alert you of web application configuration problems which could result in a vulnerable application or expose internal application details. E.g. If ‘custom errors’ are enabled in .NET, this could expose sensitive application details to a malicious user.
- Detect many more SQL injection vulnerabilities. Previously SQL injection vulnerabilities could only be found if database errors were reported or via other common techniques.
- Ability to detect SQL Injection vulnerabilities in all SQL statements, including in SQL INSERT statements. With a black box scanner such SQL injections vulnerabilities cannot be found.
- Ability to know about all the files present and accessible through the web server. Files created by attackers, to serve as a backdoor, in the application directory will be found when using the AcuSensor Technology.
- AcuSensor Technology builds a comprehensive list of all possible web application input end-points based on intercepted inputs and tests these end-points.
- No need to write URL rewrite rules when scanning web applications which use search engine friendly URL’s! AcuSensor Technology allows the scanner to rewrite SEO URLs on the fly.
- Ability to test for arbitrary file creation and deletion vulnerabilities. E.g. Through a vulnerable script a malicious user can create a file in the web application directory and execute it to have privileged access, or delete sensitive files.
- Ability to test for email injection. E.g. A malicious user may append additional information such as a list of recipients or their own text to the message body of a vulnerable web form, to spam a large number of recipients anonymously.
10. Why are security tests preferably executed on the acceptance/testing environment?
Security testing may affect the response time of the server and accuracy of data. In order to exclude this, security tests are preferably performed on the test environment (usually the same environment as the development or acceptance environment), which must be an exact copy of the production environment (live environment) for the most accurate results.
In addition, vulnerabilities can be found and exploited during a penetration test by security tools that are used to support the investigation. It is possible that data is changed or even deleted during a test. This is obviously not desirable in the production/live environment. For this reason it is important that timely backups are made (see FAQ no. 16).
For tests that are not possible on the acceptance/test environment, the research will be carried out on the production environment. This always takes place in consultation with the client.
11. The testing environment is running on the same server as the production environment. Is this a problem?
During a security test many requests are fired at the tested environment. This could have consequences for the server response time. If the test environment is operating on the same server as the production environment, security tests could have an impact on the response time of the production (live) environment.
12. Security testing with or without prior knowledge?
Security tests are executed either with or without foreknowledge. Web Security Scan advices its customers to conduct security tests with prior knowledge. The advantage is that security experts can zoom-in on specific matters deeper and quicker, resulting in more relevant findings within the available time.
Security tests without foreknowledge simulates a real life hacking situation. However, it will take up more time to scrutinize the application, at the expense of available time for investigating other parts of the application.
13. What information is needed for a security test?
Specific application information is needed to ensure the execution of security tests. To properly prepare and start a test, the following information is required per test:
(a black-box test contains the minimum required information, a grey-box test requires additional information on the black-box information and a white-box test requires additional information on the grey-box test information)
There is no knowledge of the internal structure of the objects to be tested. In the blackbox test, nothing (or only a small part) of the environment and operation is known to the tester.
- URLs of the application's acceptance and production environment.
- Acceptance environment (preferably an exact copy of the production experience). This must be at least a filled environment, otherwise certain functionalities can not be used (for more information see FAQ No. 10).
- Security tests are performed from multiple IP-addresses. For this the applicant will be asked to white-list these IP-addresses.
Grey-box test, additional information:
This is a combination of black-box and white-box and keeps the middle between them. The auditor has some prior knowledge of the environment, user data but no full administrative or management powers.
- Test accounts for the application (at least 2 accounts for each user role).
- User documentation / background information regarding the web application and any links and customization.
- Access to the acceptance environment with SSH (or else with FTP), with minimal read and write permissions on all files of the web application (is not required, leads to the most accurate results and findings).
- Possibly: previous pen test reports in case of a retest or periodic test.
White-box test, additional information:
White-box testing (also called Glass-box test / Crystal-box test) is a test strategy that uses knowledge of the internal structure or code of a program or system. The tester in question possesses prior knowledge, user login and administrative or management rights.
- Management/admin accounts for the application (preferably at least 2 sets).
- Complete documentation.
- Source code of the application.
14. How do you effectively perform a re-test?
In order to effectively perform a re-test on a previously performed pentest, it is recommended to submit the following information beforehand:
- List of vulnerabilities that have and have not been corrected and/or modified.
- Indicate what exactly is changed where, and why it has been modified. This information significantly benefits the needed test time if provided in advance.
- In case a prior pentest has been performed by another party:
- Provide old pentest reports. The tester will assess the quality of the old reports, when conducted by other parties and will provide an advise/opinion on the quality and accuracy of findings.
A re-test is based on recalculation at the standard hourly rate. As an indication: an average re-test takes 3 - 6 hours. This depends strongly on the number and type of solved vulnerabilities and the quality of the old pentest report.
15. What is the difference between a NCSC-report and OWASP Top 10-report?
The difference between the two reporting forms is that an NCSC reporting is more extensive than an OWASP Top 10 report. In addition to the identified vulnerabilities, it describes which components were found to be in order. An NCSC reporting is usually suitable for certification programs and audits for which a RPM-statement is required and is usually delivered as standard to the more extensive pentests.
What is an NCSC report?
An NCSC report is drawn up from the National Cyber Security Center's "ICT Security Guidelines for Web Applications" (version 2015). The NCSC guidelines provide guidance on safer development, management and provision of web applications and associated infrastructure. See https://www.ncsc.nl/actueel/whitepapers/ict-beveiligingsrichtlijnen-voor-webapplicaties.html for more information.
The NCSC guidelines are drafted by the government, which usually makes this a good check. Also for certification or audits (such as DigiD, ISO Certification, Mandatory Data Protection, AVG and Personal Data Protection), NCSC reporting serves as a good pollinator for the quality of security.
This report also has a management summary and comprehensive overview of all findings.
Note: this report form is only available in Dutch.
What is an OWASP Top 10 Reporting?
An OWASP Top 10 Reporting is Compiled from the OWASP Top 10 Most Common Vulnerabilities for Web Applications of the Open Web Application Security Project (OWASP). See https://www.owasp.org/index.php/Top_10_2013-Top_10 for more information. The Open Web Application Security Project (OWASP) is working on a list of the top ten security risks for web applications. The first top 10 appeared in 2003 and is intended to raise awareness about the importance of web application security. As the field evolves, this list is also updated regularly (almost annually).
This report is shorter and more technical so developers can work with it.
16. How to prepare for a pentest?
- Fill the pentest environment with (test) data:
- Tests are preferably performed on a testing/acceptation environment (see FAQ nr. 10). However, to be able to test all functionalities that are used on production environment and in real situations, it is necessary that the testing environment is filled with (test) data.
- Make backups:
- During pentesting data can be altered or removed from the tested environment. Therefore it is recommended to create backups before a pentest is performed.