Security Audit of BAHMNI EMR & HOSPITAL SERVICE Web Application Level-1 Report

Web Application Security Test Report
BAHMNI EMR & HOSPITAL SERVICE
Test URL:
https://103.210.45.155/
June 07th, 2022
Level-1
CyberQ Consulting Pvt. Ltd.

A 14-15, 3rd Floor,
Sector 59, Noida,
Uttar Pradesh-201301
INDIA
Main Switchboard: 011-40544324
E-mail:cyberq[at]cyberqindia[dot]com
for BAHMNI EMR & HOSPITAL
SERVICE web application
Copyright Notice- Proprietary Information
This document contains information that is proprietary and confidential to

CyberQ Consulting Pvt. Ltd, which shall not be disclosed outside, transmitted, or
duplicated, used in whole or in part for any purpose other than its intended
purpose. Any use or disclosures in whole or in part of this information without
express written permission of CyberQ Consulting Pvt. Ltd. is prohibited.
Any other company or product names mentioned are used for identification
purposes only, and may be trademarks of the irrespective owners.
©Copyright, CyberQ Consulting Pvt. Ltd.
07th June 2022 Confidential 2 of 43

Document Version Control

Ref. No. DNAG-ASA-G-GEM-HFW-21-125
Data Classification CLASSIFIED
Client Name Health and Family Welfare Department

Nagaland
Document Title Web Application Security Test Report
Author Mr. Arjun Singh
Reviewer By Mr. Hemant Tiwari
Version Date of Issue Issued by Change Description
1.0 07th June, 2022 CyberQ Team Initial Issue

Presented by:
Mr. Arjun Singh
Application Testing Conducted On:
2nd June 2022 to 03rd June 2022

Table of Contents
1 Introduction ....................................................................................................... 7
Purpose ....................................................................................................................... 7
Scope ............................................................................................................................ 7
Methodology.............................................................................................................. 7
Tools Used .................................................................................................................. 8
Executive Summary ............................................................................................... 8
Authority ..................................................................................................................... 8
Auditor ......................................................................................................................... 8
2 Table of Findings .............................................................................................. 9
3 Application Security Observations based on OWASP Top10,
2017 for “BAHMNI EMR & HOSPITAL SERVICE”. ................................... 12
4 Vulnerabilities with Severity Rating “High” ...................................... 13
Finding No. 1 ................................................................................................................... 13
Finding No. 2 ................................................................................................................... 15
Finding No. 3 ................................................................................................................... 17
Finding No. 4 ................................................................................................................... 19
5 Vulnerabilities with Severity Rating “Medium” ................................. 20
Finding No. 5 ................................................................................................................... 20
Finding No. 6 ................................................................................................................... 21
Finding No. 7 ................................................................................................................... 22
Finding No. 8 ................................................................................................................... 23
Finding No. 9 ................................................................................................................... 24
Finding No. 10................................................................................................................. 25
6 Vulnerabilities with Severity Rating “Low” ........................................ 26
Finding No. 11................................................................................................................. 26
Finding No. 12................................................................................................................. 27
Finding No. 13................................................................................................................. 28
Finding No. 14................................................................................................................. 29
Finding No. 15................................................................................................................. 30

Finding No. 16................................................................................................................. 32
Finding No. 17................................................................................................................. 33
Finding No. 18................................................................................................................. 34
Finding No. 19................................................................................................................. 35
7 Observations ....................................................................................................... 36
Annexure#1 ............................................................................................................ 38
Challenge Response Mechanism ...................................................................................... 38
Validate Input and Output ................................................................................................ 38
Countermeasures to protect against SQL Injection ......................................................... 39
Input Validation: ............................................................................................. 40
Modify Error Reports: .................................................................................... 41
Other Preventions: ......................................................................................... 41
Manage User Sessions/ Strong session tracking .............................................................. 41

Password Encryption ........................................................................................................ 41
Audit Trail ......................................................................................................................... 42
Browser Cache .................................................................................................................. 43

1 Introduction
Purpose
CyberQ was asked to conduct a Web Application Security Test on the application
provided by Health and Family Welfare Department Nagaland. Details were
provided to the extent mentioned in “Scope of Work”. The testing was carried out
from CyberQ Consulting Pvt. Ltd., A 14-15, 3rd Floor Sector 59, Noida
Uttar Pradesh - 201301. The objective of this testing was to ensure the
security of the network and web server from external threats through the web
application.
Scope
The audit was carried on the testing Application URL:
https://103.210.45.155/ . This was Level – 1 testing. The scope of the
project was limited to find out the vulnerable areas of the Web Application.
Exploiting the vulnerabilities was out of scope for the tests.
Methodology
The methodology applied in Web Application Security Testing is explained in the
diagram below:
Information Gathering: One of the first steps of this test is to identify the Web
application environment, including the scripting language and Web server
software in use, and the operating system of the target server. However, this
step is generally omitted if the testing is limited to just the web application and
not the host.

Test Application: While testing the application, we follow but are not limited to
the OWASP standards. The top 10 vulnerabilities are tested for static and
dynamic websites. Our testing is done manually as well as using tools. An
indicative list of tools is given in the section below.
After an exhaustive testing, the findings are compiled and classified according to
a Risk Level of High, Medium or Low depending on the harm they may cause to
the Web Application, server or to the network.
A Report is created highlighting the findings together with details for each
finding.
Tools Used
The following tools were used:
• Burp Suite
• SQLmap
• CyberQ Proprietary Checklists and Test Cases
Executive Summary
The significant issues are given in this section, the Executive summary. These list
the security flaws that are of major concern. Vulnerabilities have been given a
Severity rating of High, Medium or Low based on the risk they may pose. The
basis of giving the severity rating is as described below:
S. Severity
Basis of giving severity rating
No. Rating
1 High Severely impact the system
2 Medium Impact the system in a limited manner
3 Low No direct impact on the system
Suggested improvements which are not non-
4 Information
compliances but would help in further enhancements
Authority
The Web Application Security Test was conducted under the authority of
Miss. Manenkala Longkumer (ICT Consultant).
Auditor
Mr. Arjun Singh

2 Table of Findings
The following key findings support our assessment of the weaknesses associated
with the application.
S. No. Severity Vulnerability Description Level-1 Remarks

This test is to check whether
the cookie can be reused in
another computer during the
login phase. The server
maintains the user state
between any client and itself by
exchanging the cookie for each
request-response between
1 High them. If this unique identifier is Open -
not removed from the state
table of the web application
server when user tries to login
the same account from another
computer then any request
subsequent to the user login will
be happily serviced by the web
application, (Session Hijacking).
The password between server
and client is passed in clear
text. It is possible for a
2 High Open -
malicious user to sniff into the
network and access the
application and password.
There is no limit on number of
incorrect passwords retries
3 High while trying to login. Thus, Open -
Brute force attack is possible in
the Application.
It is possible to upload
4 High malicious (.exe) file in the Open -
application.
Old and vulnerable version of
5 Medium Open -
jQuery is being used.


Banner grabbing (which may
help attacker to learn more
6 Medium Open -
about his target) is possible in
the application.
There is no CAPTCHA
7 Medium implemented in public dynamic Open -
pages in the application.
Application is displaying the
8 Medium Open -
runtime error to the end user.
Security headers such as (X-

Content-Type-Options, X-
Medium Frame-Options, Strict-
9 Open -
Transport-Security, X-XSS, and
Content-Security-Policy) are
missing in Application.
Cross-site Tracing (XST) is
10 Medium Open -
possible in the Application.
Path is set to default root i.e.
11 Low '/'. Open -
HTTP Methods (OPTIONS) are

12 Low enabled in the application. Open -
There is no session timeout

13 Low implemented in the application. Open -
Application has the provision to

remember all user names those
have logged in or try to log in.
14 Low Autofill is not disabled on login. Open -
Other fields can also display
information, which can be
misused by a malicious user.
Password History is not
15 Low maintained in the application. Open -
Max length is not defined

16 Low properly in the application. Open -
Third party URL open in same

17 Low tab in the application. Open -


Cookie id display without secure
18 Low flag in the application. Open -
HttpOnly flag is not set properly

19 Low in the application. Open -

3 Application Security Observations based on OWASP

Top10, 2017 for “BAHMNI EMR & HOSPITAL SERVICE”.
Open Web Applications Security Project (OWASP) has included the different
vulnerabilities in its OWASP Top 10 2017, list found in web applications worldwide.
The table shows how the application stacks up with respect to the OWASP top 10
lists.
S. No. OWASP 2017 Vulnerabilities Status
1. Injection Safe
2. Broken Authentication Unsafe
3. Sensitive Data Exposure Unsafe
4. XML External Entities (XXE) Safe
5. Broken Access Control Unsafe
6. Security Misconfiguration Unsafe
7. Cross-Site Scripting (XSS) Safe
8. Insecure Deserialization Safe
9. Using Components with Known Vulnerabilities Unsafe
10. Insufficient Logging & Monitoring Unsafe
OWASP 2013 Vulnerabilities
11. Cross-Site Request Forgery (CSRF) Safe
OWASP 2010 Vulnerabilities
12. Malicious File Execution Unsafe
13. Denial Of Service Unsafe

4 Vulnerabilities with Severity Rating “High”

Finding No. 1
Description: This test is to check whether the cookie can be reused in another
computer during the login phase. The server maintains the user state between
any client and itself by exchanging the cookie for each request-response
between them. If this unique identifier is not removed from the state table of the
web application server when user tries to login the same account from another
computer then any request subsequent to the user login will be happily serviced
by the web application, (Session Hijacking).
Severity Level: High
Recommendation: 1. Add a new cookie that randomly changes for each login
attempt. Generate different session id before and after authentication. Also
every request after the successful authentication should be associated with an
extra auth cookie: It is possible to view the sensitive information by fetching the
page from the cache option of the browser. session identifier cookie which also
randomly changes and expires when user logs out from the application or closes
the browser. For example;
Cookie: AUTHCookie=69BK7F0D8KL; ASP.NET_SessionId= JNHG7H0LKJ57CF4;

Cookie: AUTHCookie=5A0KN5F9ER5; ASP.NET_SessionId= JNHG7H0LKJ57CF4;
Cookie: AUTHCookie=CG4K8L3T5H; ASP.NET_SessionId= JNHG7H0LKJ57CF4;
Cookie: AUTHCookie=L6D3G0JA3S; ASP.NET_SessionId= JNHG7H0LKJ57CF4.
2. SSL should be implemented..
Screenshots:
Step#1: In the authenticated session, refresh the page and capture the request.
Now copy authenticated URL and cookie as shown below:

Step#2: Now open another browser, paste and hit the copied URL. Replace the
cookie with the authenticated one that we’ve copied from browser 1. And turn
the intercept off.
Step#3: As you can see, we are able to access the authenticated pages without
entering the credentials. Thus, Session Hijacking is possible in Application.

Finding No. 2
Description: The password between server and client is passed in clear text. It
is possible for a malicious user to sniff into the network and access the
application and password.
Recommendation: Salt hashing is not implemented at login, thus password
travels in clear text. So, it is recommended to implement the hashing
technique/algorithm used at login in the application. Password should be
encrypted every time while being transmitted over the network. The solution is
to implement:
a) Salted SHA-256 technique in authentication or login module and
b) SHA-256 hash technique in change password and reset password modules.
The pre-requisite to this is that the backend database stores a SHA-256 hash of
the password. (SHA-256 hash is a cryptographic technique in which the actual
value can never be recovered). Here is how the salted SHA-256 technique works:
When a client requests for the login page, the server generates a random
number, the salt, and sends it to the client along with the page. A JavaScript
code on the client computes the SHA-256 hash of the password entered by the
user. It then concatenates the salt to the hash and re-computes the SHA-256
hash. This result is then sent to the server. The server picks the hash of the
password from its database, concatenates the salt and computes the SHA-256
hash. If the user entered the correct password these two hashes should match.
The server compares the two and if they match, the user is authenticated.
Screenshots:
Case 1: As you can see change password is travel in clear text.

Case 2: As you can see password is travel in clear text.

Finding No. 3
Description: There is no limit on number of incorrect password retries while
trying to login. Thus, Brute force attack is possible in the Application.
Recommendation: Users should be restricted to a defined number of login
attempts per unit of time. After that defined number of login attempt,
application should block that user account or CAPTCHA can be implemented at
login page. This way automated attempt to login can be checked and brute force
attacks can be prevented.
CAPTCHA should follow the following condition:
a) The combination of alphanumeric value.
b) Combination of Upper case and lower-case letters.
c) Case-Sensitive
d) Its length should be minimum 6 characters.
e) Should not be a third-party CAPTCHA:
f) Should be Random and not follow a pattern.
g) Example: Ab73jy, PT34h8, Hos3t3, nic23n etc.
Screenshots:
Step#1: Enter the credentials, click on login button and capture the request.
Right click on captured request and click on send to intruder button as shown
below:

Step#2: In intruder, select the password and click on add button-> Go to

payloads-> Enter the random values for password including valid password->
Click on Start attack button.
Step#3: As you can see in below snapshot, the valid password has lowest
length value. Thus, Brute force attack is possible in the Application.

Finding No. 4
Description: It is possible to upload malicious (.exe) file in the application.
Recommendation: Following things should be implemented in file upload
module:
• Inspect the content of uploaded files, and enforce a white list of accepted,
non-executable content types. Additionally, enforce a blacklist of common
executable formats, to hinder hybrid file attacks.
• Enforce a white list of accepted, non-executable file extensions.
• If uploaded files are downloaded by users, supply an accurate non-generic
Content-type header, and also a Content-disposition header which
specifies that browsers should handle the file as an attachment.
• Enforce a size limit on uploaded files (max 8-10 MB); this can be
implemented both within application code and in the web server's
configuration.
• Reject attempts to upload archive formats such as ZIP.
• Multiple file extension like test.pdf.txt.php.jif.jpg should not be allowed for
upload.
Validations at server end are mandatory.
Proper checks to be put on Content type and MIME type as well.
Screenshots:
Case 1: upload the .pdf file which is converted from .exe extension to .jpg file.
Click on Add button and capture the request. As you can see malicious file is
travelling from client end to server end. As you can see, the file will be uploaded
successfully.

5 Vulnerabilities with Severity Rating “Medium”
Finding No. 5
Description: Old and vulnerable version of jQuery is being used.
Severity Level: Medium

Recommendation: It is recommended that application should use latest/Stable
version of jQuery (at least 3.5.1 or 3.6.0).
Screenshots:

Finding No. 6
Description: Banner grabbing (which may help attacker to learn more about his
target) is possible in the application.
Recommendation: The versions should be hidden or should not be displayed to

end user.
Screenshot:
Step#1: As you can see that the server’s name and version is disclosed.

Finding No. 7
Description: There is no CAPTCHA implemented in public dynamic pages in the
application.
Recommendation: Users should be restricted to a defined number of logins
attempts per unit of time. After that defined number of login attempt,
application should block that user account or CAPTCHA can be implemented at
login page. Application should validate CAPTCHA at both client and server ends.
Both client and server-side validation are mandatory.
CAPTCHA should follow the following condition:
a) The combination of alphanumeric value.
b) Combination of Upper case and lower-case letters.
c) Case-Sensitive
d) Its length should be minimum 6 characters.
e) Should not be a third-party CAPTCHA:
f) Should be Random and not follow a pattern.
g) Example: Ab73jy, PT34h8, Hos3t3, nic23n etc.
Screenshots:

Finding No. 8
Description: Application is displaying the runtime error to the end user.

Recommendation: Application should not generate detailed / informative /
runtime error messages to the user. Implement a customized error
message/page against all such errors. Application must generate customized
error messages to the end user in case any error occurs in the application and
customized messages should not reveal any sensitive information in context to
the application.
Screenshot:
Case#1: Forbidden error which disclosing Server related information.
Case#2: show the improper error handling.

Finding No. 9
Description: Security headers such as (X-Content-Type-Options, X-Frame-
Options, Strict-Transport-Security, X-XSS, and Content-Security-Policy) are
missing in Application.
Recommendation: Following HTTP response security headers must be
implemented:
Header Rationale
The majority of CSP functionality only
Content-Security-Policy
affects pages rendered as HTML.
To require connections over HTTPS and
HTTP Strict-Transport-Security
to protect against spoofed certificates.
To prevent browsers from performing
X-Content-Type-Options MIME sniffing, and inappropriately
interpreting responses as HTML.
To protect against drag-and-drop style
X-Frame-Options
clickjacking attacks.
X-XSS header protects against Cross-
X-XSS-Protection
Site Scripting attacks.
Screenshots:

Finding No. 10
Description: Cross-site Tracing (XST) is possible in the Application.
Recommendation: xc
Screenshots:
Step#1: As you can see that we are change the http method Get to TRACE and
the sent the request see the response.

6 Vulnerabilities with Severity Rating “Low”

Finding No. 11
Description: Path is set to default root i.e. '/'.
Severity Level: Low
Recommendation: Verify that the path attribute, just as the Domain attribute,
has not been set too loosely. Even if the Domain attribute has been configured
as tight as possible, if the path is set to the root directory "/" then it can be
vulnerable to less secure applications on the same server.
Screenshot:

Finding No. 12
Description: HTTP Methods (OPTIONS) are enabled in the application.
Severity Level: Low
Recommendation: HTTP methods should be disabled in the application which
may prevent the application from security breach. Only GET and POST method
should be enabled in the application.
Screenshots:
Case#1: OPTIONS Methods are enabled.

Finding No. 13
Description: There is no session timeout implemented in the application.
Severity Level: Low
Recommendation: Application should terminate a session if there is no

activity from the user-side for a fixed period of time, e.g., 15 minutes.
Screenshot:

Finding No. 14
Description: Application has the provision to remember all user names those
have logged in or try to log in. Autofill is not disabled on login. Other fields can
also display information, which can be misused by a malicious user.
Severity Level: Low
Recommendation: Application should not have the option to remember

usernames as this may cause unavailability of services to valid users.
AutoComplete option should be turned off by the application so as to override
any settings by the user from the browser.
Screenshot:

Finding No. 15
Description: Password History is not maintained in the application.
Severity Level: Low
Recommendation: Users should be prevented from reusing their current or

previous 3 passwords. Password history should ideally be 3.
Screenshot:
Step 1: In this step we are using first password (adminADMIN11) then click on
submit button and as you can show the password has been changed.
Step 2: In this step we are changing the password for the second time and
using another password (adminADMIN12) then click on submit button and as
you can show the password has been changed.

Step 3: In this step we are changing the password for the third time and using
same password (adminADMIN!) then click on submit button and as you can
show the password has been changed. As you can see the below screenshot.

Finding No. 16
Description: Max length is not defined properly in the application.
Severity Level: Low
Recommendation: Input-field length must be defined properly.
Screenshot:

Finding No. 17
Description: Third party URL open in same tab in the application.
Severity Level: Low
Recommendation: Third party URL open must be another tab.
Screenshot:
Step 1: As you can see that we are click on help link show as a below.
Step 2: As you can see that third party URL open same tab.

Finding No. 18
Description: Cookie id display without secure flag in the application.
Severity Level: Low
Recommendation: it is mandatory that cookie transmitted over the network

with secure (HTTPonly) flag.
Screenshot:

Finding No. 19
Description: HttpOnly flag is not set properly in the application.
Severity Level: Low
Recommendation: HttpOnly flag should be set to “True” in website’s

configuration file.
Screenshot:
Step#1: As you can see that open the inspect the page and go to console and
write the command javascript:alert(document.cookie); and see as below the
HttpOnly flag is not set in the application.

7 Observations
1. The application does not maintain audit trail properly where all user activities
have to be logged. In-case a malicious user tries to attack the application;
the application will not be able to trace the attacker.
Recommendation(s): An Audit trail should be incorporated in the application

admin module, where all user activities have to be logged. Following points
should be considered:
• Audits are to be generated at the time of resource access and by the same
routines accessing the resource
• Information to be logged including the following: IP of the originating client,
Date, Time, username if any in addition to other details to be logged in the
web server.
• These IP, date, time, session details, user details (NO password), referrer,
process id to be logged in application logs.
• To create audit logs use auto numbering so that every logged entry has a log
number, which is not editable. Then if one audit entry is deleted a gap in the
numbering sequence will appear.
• Log entries are to be hashed/signed so that changes to audit log can be
detected.
Audit trails to answer the following:

• Logging of Authentication Process. Success and failed attempts.
• Logging Authentication details and changes.
• Software error and failures logged
• Should not be possible to retrieve confidential authentication information from
these logs (including passwords)
• Is it possible to uniquely identify both client host and user from these logs?
• What level of information is logged by the application (read/write access,
modification data, and copy/paste data)?
• Are log files time sequential and can they positively identify the time of action.
The screenshot for recommended audit trail is given below.

2. Forgot Password module is not implemented in the application.
3. The module is not working properly in the application.

Annexure#1
Challenge Response Mechanism

Automated posting can cause a DOS attack. CAPTCHA should be implemented
where such an attack is possible to ensure manual entry. CAPTCHA (Completely
Automated Public Turing test to tell Computers and Humans Apart) is a type of
challenge-response test used in computing to determine whether or not the user
is human.
The challenge is a randomly generated unique string superimposed on an image.
This string is displayed on the form where user input is required. The user has to
then enter this string along with the data he would like to fill in the form. This
data received from the user must be processed only if the string that the user
enters matches with the one that was displayed to him.
A mechanism to maintain the association of the text displayed by the server and
the text entered by the user should be established.
Validate Input and Output

The input that the server receives from the user can lead to malicious code
entering the server. Similarly, the output shown to the user can transmit
malicious code to the client system. All user input and output should be checked
to ensure it is both appropriate and expected. Input validation should be
performed on the client-side as well as on the server-side.
There are three main models to think about when designing a data validation
strategy.
1. Accept Only Known Valid Data
a. A character set may be defined for each field where input from the user is
accepted. E.g. “A-Z, a-z, @, ., 0-9, _” is a character set for a field that accepts
user email.
2. Reject Known Bad Data
a. A character set of bad data may be defined for the site that has to be rejected.
E.g. “CREATE, DROP, OR”
3. Sanitize Known Bad Data
a. A character set of bad data is defined and any input field that has such a
character is modified. E.g. “If there is a single quote (‘) in the data, it is replaced
with two single quotes.
All methods must check:

1. Data Type
2. Syntax
3. Length

It is recommended to use the strategy of “Accept only known data”. Further all
the allowed input/output data must be sanitized on the server side by replacing
scripts tags, sent as part of user input/output, with appropriate representations.
For example
“<” by <
“>” by >
“(“ by&#40
This would avoid scripts from being executed on the client side.
Client side input must also be checked for URL encoded data. URL encoding
sometimes referred to as percent encoding, is the accepted method of
representing characters within a URI that may need special syntax handling to
be correctly interpreted. This is achieved by encoding the character to be
interpreted with a sequence of three characters. This triplet sequence consists of
the percentage character “%” followed by the two hexadecimal digits
representing the octet code of the original character. For example, the US-ASCII
character set represents a space with octet code 32, or hexadecimal 20. Thus its
URL-encoded representation is %20.
Other common characters that can be used for malicious purposes and their URL
encoded representations are: -
# Character URL encoded
‘ %27
“ %22
; %3b
< %3c
= %3d
> %3e
) %29
( %28
All input validation checks should be completed after the data has been decoded
and validated as acceptable content (e.g. maximum and minimum lengths,
correct data type, does not contain any encoded data, textual data only contains
the characters a-z and A-Z etc.)
Note: The task of input validation must be done throughout the

application. It is an absolute necessity that all validation must also be
performed on the server side.
Countermeasures to protect against SQL Injection

As SQL injection occurs due to poor coding and poor website administration the
following steps can be taken to avoid SQL injection.
Input Validation:
a. Escape Quotes:
Replace all single quotes to two single quotes:
<%
functionrepQuotes(strWords)
repQuotes = replace(strWords, “’”, “””)
end function
%>
b. Sanitize the input or Remove Culprit Characters:

All client-supplied data needs to be cleansed of any characters or strings that
could possibly be used maliciously. Character sequences such as;, --, select,
insert and xp_ can be used to perform an SQL injection attack .So remove them
by creating function like
rem_culp_char.
<%
functionrem_culp_char(strwords)
dimbadChars
dimnewChars
badStuff = array(“select”,”union”,”drop”,”;”, “—“, “insert”, “delete”,
“xp_”, “*”)
newChars = strWords
fori = 0 to uBound(badChars)
newChars = replace(newChars, badStuff(i),””)
next
rem_culp_char = newChars
end function
%>
Using repQuotesin combination with rem_culp_chargreatly removes the chance

of any SQL injection attack
For example:
\select Person_name from employee where emp_id= 601; xp_cmdshell

'format c: /q /yes '; drop database myDB; --
and run the query through repQuotesand then rem_culp_char, the query would
end up looking like this:
Person_name from employee where emp_id=1 cmdshell ''format c:
/q /yes '' database myDB
The above query is useless i.e. it will not run

c. Limit the Length of User Input:

Keep all text boxes and form fields as short as possible.
While accepting a query string value for a product ID or the like, always use a
function to check if the value is actually numeric, such as the Is Numeric()
function for ASP.
Always Use method attribute set to POST.
Modify Error Reports:

To avoid SQL injection developer should handle or configure the error reports in
such a way that error cannot be shown to outside users. In these error reports
some time full query is shown, pointing to the syntax error involved, and
attacker could use it for further attacks. Display of errors should be restricted to
internal users only.
Other Preventions:
The default system account for Oracle should never be used
If extended stored procedures are not used, or have unused triggers, stored
procedures, user-defined functions, etc, then remove them, or move them to an
isolated server. Most extremely damaging SQL injection attacks attempt to make
use of several extended stored procedures such as cmd-shell and grant login, so
by removing them, theoretically blocking the attack before it can occur.
Note: To execute stored procedures user or database should have necessary
privileges.
Isolate database server and web server. Both should reside on different
machines.
Manage User Sessions/ Strong session tracking

Session tokens (Cookies) must be strongly tied to a specific HTTP client/user
instance. Each user request variable must be checked for proper binding with
the Cookie before allowing the requested action. This would help to prevent
hijacking and replay attacks.
(HTTP is a stateless protocol wherein the web server responds to each client
request without remembering the previous requests made and cannot link a set
of requests. Being able to separate and recognize user actions to specific
sessions is critical to web security.)
Password Encryption
The Login Name and Password should be encrypted while being transmitted over
the network. Changing the application protocol from HTTP to HTTPS would

mitigate this problem. Using HTTPS would transmit all the traffic between user
and server in encrypted format
The solution is to implement the salted SHA 256 or latest hashing technique. The
pre-requisite to this is that the backend database stores a SHA 256 hash of the
password. (SHA256 hash is a cryptographic technique in which the actual value
can never be recovered).
Here is how the salted SHA256 or latest hashing technique works:
When a client requests for the login page, the server generates a random
number, the salt, and sends it to the client along with the page. A JavaScript
code on the client computes the SHA256 hash of the password entered by the
user. It then concatenates the salt to the hash and re-computes the SHA256
hash. This result is then sent to the server. The server picks the hash of the
password from its database, concatenates the salt and computes the SHA256
hash. If the user entered the correct password these two hashes should match.
The server compares the two and if they match, the user is authenticated.
Audit Trail
An Audit trail should be incorporated in the application admin module, where all
user activities have to be logged. Following points should be considered:
1. Failure login attempts.
2. User ID of successful logins.
3. All events/actions triggered by authenticated users.
4. Software Errors/Failures.
5. IP of the originating client can also be logged.
6. Timestamp (Date, Time) must be logged against each log entry.
7. Each log entry in the log file should have a unique identity number.
8. No confidential information like password, credit card number should ever be
logged.
9. There should be a functionality of reporting the logged-in information from the
log file to the administrator. An additional option can be added to the admin
module to view this information.
10. After a stipulated timeframe, online logs can be removed and stored offline.
11. Periodic backups/restores are essential.
12. Only “Admin” user should access “Audit Trail” and “Action Trail”. All actions
in the application should be recorded in the “Action Trail”.
Note: The application critical actions like “Change Password”, “User Creation”,
“File Upload” and other critical actions should be recorded in “Action Trail” page.
Both successful and unsuccessful actions should be recorded.

Browser Cache
• The browser has a capability to temporarily store some of the pages browsed.
These cached files are stored in a folder, like the Temporary Internet Files folder
in the case of Internet Explorer. When we ask for these pages again, the
browser displays them from its cache. This is much faster than downloading the
page from the server.
• The response header sent from the server has some cache control directives
that can be set from the code. These directives control the caching of content on
the client browser. The directives to be set are cache-control: no-cache or
cache-control: no-store.
• The no-cache directive in a response indicates that the response must not be
used to serve a subsequent request i.e. the cache must not display a response
that has this directive set in the header but must let the server serve the
request. The no-cache directive can include some field names; in which case the
response can be shown from the cache except for the field names specified
which should be served from the server. The no-store directive applies to the
entire message and indicates that the cache must not store any part of the
response or any request that asked for it.
• These directives solve the problem of caching to some extent but not
completely, since no-cache and no-store are not supported by HTTP 1.0 caches.
Also, we have observed that non-html content types like pdf and Excel
spreadsheets get cached on the browser even when the above tags are set.

Security Audit of BAHMNI EMR & HOSPITAL SERVICE Web Application Level-1 Report

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Security Audit of BAHMNI EMR & HOSPITAL SERVICE Web Application Level-1 Report

Uploaded by

Copyright:

Available Formats

Web Application Security Test Report

BAHMNI EMR & HOSPITAL SERVICE

June 07th, 2022

CyberQ Consulting Pvt. Ltd.

Sector 59, Noida,

Main Switchboard: 011-40544324

Copyright Notice- Proprietary Information

This document contains information that is proprietary and confidential to

©Copyright, CyberQ Consulting Pvt. Ltd.

07th June 2022 Confidential 2 of 43

Document Version Control

Client Name Health and Family Welfare Department

Author Mr. Arjun Singh

Reviewer By Mr. Hemant Tiwari

Version Date of Issue Issued by Change Description

1.0 07th June, 2022 CyberQ Team Initial Issue

07th June 2022 Confidential 3 of 43

Web Application Security Test Report

Mr. Arjun Singh

Application Testing Conducted On:

2nd June 2022 to 03rd June 2022

07th June 2022 Confidential 4 of 43

Finding No. 15................................................................................................................. 30

Modify Error Reports: .................................................................................... 41

Other Preventions: ......................................................................................... 41

Manage User Sessions/ Strong session tracking .............................................................. 41

07th June 2022 Confidential 6 of 43

07th June 2022 Confidential 7 of 43

07th June 2022 Confidential 8 of 43

S. No. Severity Vulnerability Description Level-1 Remarks

07th June 2022 Confidential 9 of 43

S. No. Severity Vulnerability Description Level-1 Remarks

Security headers such as (X-

HTTP Methods (OPTIONS) are

There is no session timeout

Application has the provision to

Max length is not defined

Third party URL open in same

07th June 2022 Confidential 10 of 43

S. No. Severity Vulnerability Description Level-1 Remarks

HttpOnly flag is not set properly

07th June 2022 Confidential 11 of 43

3 Application Security Observations based on OWASP

S. No. OWASP 2017 Vulnerabilities Status

2. Broken Authentication Unsafe

3. Sensitive Data Exposure Unsafe

4. XML External Entities (XXE) Safe

5. Broken Access Control Unsafe

6. Security Misconfiguration Unsafe

7. Cross-Site Scripting (XSS) Safe

8. Insecure Deserialization Safe

9. Using Components with Known Vulnerabilities Unsafe

10. Insufficient Logging & Monitoring Unsafe

OWASP 2013 Vulnerabilities

11. Cross-Site Request Forgery (CSRF) Safe

OWASP 2010 Vulnerabilities

12. Malicious File Execution Unsafe

13. Denial Of Service Unsafe

07th June 2022 Confidential 12 of 43

4 Vulnerabilities with Severity Rating “High”

Cookie: AUTHCookie=69BK7F0D8KL; ASP.NET_SessionId= JNHG7H0LKJ57CF4;

07th June 2022 Confidential 13 of 43

07th June 2022 Confidential 14 of 43