audigitalhealth / amt-flat-file-generator Goto Github PK

amt-flat-file-generator-master\amt-flat-file-generator-master\src\main\java\au\gov\digitalhealth\terminology\amtflatfile\Amt2FlatFile.java, 100

Observation: Code is taking the input from command line arguments and there is no validation for data , this could lead to malicious attacks.

Risk: Unchecked input is the leading cause of vulnerabilities in  applications . These often leads to cross-site scripting, process control, and SQL injection vulnerabilities, among others. Although applications are not generally susceptible to memory corruption attacks, if an application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the application to launch a buffer overflow attack and many other attacks.

Enable whitelist validations for all the inputs to avoid malicious attacks. If the application is displaying the data on UI, it is recommended to implement output encoding .

amt-flat-file-generator-master\amt-flat-file-generator-master\src\main\java\au\gov\digitalhealth\terminology\amtflatfile\AmtCache.java, 56

Observation: Application code is getting a file from the root path, allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Risk: In application code directly embedding a file name or a path for the file name in the program to access the system resources could be cleverly exploited by a malicious user who may pass an unexpected value for the argument and the consequences of executing the program, especially if it runs with elevated privileges, with that argument may turn out to be fatal. Thus, Path Manipulation vulnerability is a very serious issue and should be definitely not left unattended in a code. Such a vulnerability may enable an attacker to access or modify otherwise protected system resources.

The best way to prevent path manipulation is with a level of indirection: create a list of legitimate resource  names that a user is allowed to specify, and only allow the user to select from the list. With this approach the input provided by the user is never used directly to specify the resource name. In some situations this approach is impractical because the set of legitimate resource names is too large or too hard to keep track of.

A better approach is to create a whitelist of characters that are allowed to appear in the resource name and accept input composed exclusively of characters in the approved set.

amt-flat-file-generator-master\amt-flat-file-generator-master\src\main\java\au\gov\digitalhealth\terminology\amtflatfile\AmtCache.java, 23,25,27

Observation: PREFERRED, FSN and AMT_MODULE_ID these variables are given hardcoded values, exposing this information to attackers. Anyone who has access to the class files can decompile them and discover the sensitive information.

Risk: The hard-coded Sensitive information is visible to the project developers, who can use these Sensitive informations to break into the respective system [Application / Database]. When the attacker or a devious employee who has the access to the executables of the application, he/she can disassemble the code, which will contain the Sensitive information. This could impact the confidentiality and availability of the application.

Sensitive information should be encrypted with strong encryption algorithm like AES with 256 bit key length or hashed using SHA-256 or above.

amt-flat-file-generator-master\amt-flat-file-generator-master\src\main\java\au\gov\digitalhealth\terminology\amtflatfile\AmtCache.java, 58,59,60,61,62

Observation: Application code is reading the file with out validating it. This can lead to malicious file upload attacks. Risk: In application  code maximum file size and maximum name length are not defined, so it may lead to: Overwriting an existing file – If a file is uploaded with the same name and extension as an existing file on the server, this could overwrite the existing file. If the file that was overwritten is a critical file, the new file can potentially be used to launch a server-side attack. This could cause the website to no longer function, or it could change security settings to allow attackers to upload further malicious files. Malicious content – If the uploaded file contains an exploit, malware, malicious script or macro, the file could be used to gain control of the server or infect users’ machines. Very large file upload – If an extremely large file is uploaded, this could cause a Denial of Service (DDos) attack and bring down the site.

we recommend the following best practices to avoid malacious file upload:
1. Only allow specific file extensions
2. Verify file types
3. Scan for malware
4. Remove possible embedded threats
5. Set a maximum name length and maximum file size
6. Randomize uploaded file names
7. Store uploaded files outside webroot
8. Check for vulnerabilities in files
9. Use simple error messages

amt-flat-file-generator-master\amt-flat-file-generator-master\src\main\java\au\gov\digitalhealth\terminology\amtflatfile\Amt2FlatFile.java, 114

Observation: Application code is using system.err.println .Using System.err rather than a dedicated logging facility makes it difficult to monitor the behavior of the program.

Risk: Using System.out or System.err rather than a dedicated logging facility makes it difficult to monitor the behavior of the program. It can also cause log messages accidentally returned to the end users, revealing internal information to attackers.

Use standard java logging mechanism rather than system.err.println