Proper Validation of email pattern while creating a new user #7354
+34
−593
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Incorrect email pattern is being accepted while creating a new user.The email format is not strongly validated against defined schema patterns this can be considered as a vulnerability.
Fix #7352
Short description of what this resolves:
The vulnerability in this case involves improper validation of email addresses within the OpenEMR application. Specifically, the email address field for "Google Email for Login" allows submission of improperly formatted email addresses, such as 'user@'. This issue arises due to:
Lack of Server-side Validation: The email input is not validated on the server side to ensure it conforms to a proper email format. This can lead to potential security risks where invalid email formats are accepted, which could be exploited in various ways depending on other linked functionalities or integration points.
Potential for Inconsistent Data: Storing improperly validated emails can lead to data integrity issues. For example, communication mechanisms that rely on these emails may fail, leading to operational disruptions.
Compliance and Standard Practice Issues: Not validating input data such as email addresses according to a strict schema (which includes allowed characters, length, and pattern) violates best practices and specific compliance requirements
Changes proposed in this pull request:
Dual-layer Validation: By implementing both client-side and server-side validations, the application ensures that email address inputs are checked twice—once in the browser before the data is sent, and again on the server before it is processed. This mitigates the risk of malformed or malicious data slipping through due to client-side modifications (like disabling JavaScript).
Improved Data Integrity: Proper email validation ensures that only valid emails are stored in the database, which is crucial for the reliability of any features that use these emails, such as user notifications, password resets, etc.
User Feedback and Interaction: The JavaScript alert provides immediate feedback to the user, which can prevent confusion and ensure that users know their data must be corrected before proceeding. This improves usability and user experience.
Compliance and Best Practices: Implementing stringent input validation is in line with best practices for web development and specific security standards mentioned in the ASVS and CWE catalogs, thereby reducing potential compliance risks.