The document analyzes the error handling and logging verification requirements for MediaWiki version 8. Several tools were used to analyze MediaWiki including RIPS, VCG, VEGA, Acunetix. The analysis found that MediaWiki partially satisfies requirements around not outputting sensitive error messages, logs, and data. It was also found that logs should be better protected and distinguish trusted and untrusted data. The conclusion recommends discussing security design choices with developers and notes that RIPS, VCG, and Acunetix were most effective for source code analysis.

1. ANALYSIS OF MEDIAWIKI
V8: ERROR HANDLING AND LOGGING VERIFICATION REQUIREMENT
MOHAMAD HASSAN
OBAIDULLAH IZAM
ELIAS TOSS
MAY 30,2018

2. TOOLS USED FOR ANALYSIS
RIPS VCG VEGA ACUNETIX

3. A GLANCE
OWASP Security Knowledge Framework. The OWASP Security Knowledge
Framework is intended to be a tool that is used as a guide for building and
verifying secure software. It can also be used to train developers about application
security.
MediaWiki is a free and open-source server based application, It was originally
developed by the Wikimedia Foundation and It is written in the PHP programming
language and allows its users to add, modify or remove content through a web
browser.

4. V8 ANALYSIS
# Description Satisfied
8.
1
Verify that the application does not output error messages
or stack traces containing sensitive data that could assist
an attacker, including session id, software/framework
versions and personal information
Partial
8.
2
Verify that error handling logic in security controls denies
access by default.
YES
8.
3
Verify security logging controls provide the ability to log
success and particularly failure events that are identified as
security-relevant.
YES
8.
4
Verify that each log event includes necessary information
that would allow for a detailed investigation of the timeline
when an event happens.
YES
8.
5
Verify that all events that include untrusted data will not
execute as code in the intended log viewing software.
Partial

5. V8 ANALYSIS
# Description Satisfied
8.6 Verify that security logs are protected from unauthorized
access and modification.
YES
8.7 Verify that the application does not log sensitive data as
defined under local privacy laws or regulations,
organizational sensitive data as defined by a risk
assessment, or sensitive authentication data that could
assist an attacker, including user’s session identifiers,
passwords, hashes, or API tokens.
Partial
8.8 Verify that all non-printable symbols and field separators
are properly encoded in log entries, to prevent log
injection
YES
8.9 Verify that log fields from trusted and untrusted sources
are distinguishable in log entries.
YES
8.1
0
Verify that an audit log or similar allows for
nonrepudiation of key transactions.
YES

6. V8 ANALYSIS
# Description Satisfied
8.1
1
Verify that security logs have some form of integrity
checking or controls to prevent unauthorized
modification.
Don’t know
8.1
2
Verify that the logs are stored on a different partition than
the application is running with proper log rotation.
YES
8.1
3
Time sources should be synchronized to ensure logs have
the correct time
YES

7. V8.1
• Verify that the application does not output error messages or stack traces
containing sensitive data that could assist an attacker, including session id,
software/framework versions and personal information.
• Analysed with Acunetix
• It contains possible sensitive information (e.g. a password parameter) and could be
potentially cached. Even in secure SSL channels sensitive data could be stored by
intermediary proxies and SSL terminators. To prevent this, a Cache-Control header
should be specified
• How to fix this vulnerability
Prevent caching by adding "Cache Control: No-store" and "Pragma: no-cache" to the
HTTP response header.

8. V8.1
• Analysed with VCG
• This debugging function can expose sensitive data to an
attacker.
• Potentially Unsafe Code – phpinfo
• Line: 1385 -
C:xampphtdocsmediawikivendorsymfonyprocessProcess.php
• if (!function_exists('phpinfo') || defined('HHVM_VERSION')) {

9. V8.4
• Verify that each log event includes necessary information that would allow
for a detailed investigation of the timeline when an event happens.
• Manual Review
• Manual reviewing was performed for verification of V8.4 and was seen
that all the log events include information which could allow for detailed
investigation and below is a snapshot of the log file.

10. V8.7
• Verify that the application does not log sensitive data as defined under local
privacy laws or regulations, organizational sensitive data as defined by a risk
assessment, or sensitive authentication data that could assist an attacker,
including user’s session identifiers, passwords, hashes, or API tokens.
• Analysed with Acunetix
• This application contains a session token in the query parameters. A session token is
sensitive information and should not be stored in the URL. URLs could be logged or leaked
via the Referrer header.
• The impact of this vulnerability
• Possible sensitive information disclosure.
• How to fix this vulnerability
• The session should be maintained using cookies (or hidden input fields).

11. V8.8
• Verify that all non-printable symbols and field separators are
properly encoded in log entries, to prevent log injection
• Manual Review
• Conducted a manual reveiw of the log entries and detected that log
entries are encoded with non-printable symbols which avoids the log
injection.

12. CONCLUSION
• About tools: We used different tools for the analysis such as
(RIPS, ZAP, VEGA, VCG and ACCUNETIX) and among them we
found RIPS, VCG and ACCUNETIX more efficient and fruitful for
performing the source code analysis in terms of ease of use,
fast and accurate detection of the vulnerabilities.
• Security: We consider that to test the safety of an application is
very necessary to a direct discussion about the design choices
with the developers.

13. Thanks for your attention!
Questions