### Description

A stored XSS vulnerability has been found in Church CRM when the application default setting is open to register the family without the login. 

- ChurchCRM version: 5.8.0
- ChurchCRM is running with docker.
- PHP version the server running: 8.3.7
- vulnerable parameter : Family Info
- Severity : High
- payload : `"><img src=x onerror=alert(2)>`

### Steps To Reproduce

1. Logout your account and navigate to login page.
![image](https://github.com/ChurchCRM/CRM/assets/6739256/cb8505cf-6f48-450f-9c2e-c863c4862037)

2. Click on Register a new Family and add the payload `"><img src=x onerror=alert(2)>` in Family name text field and register.
![image](https://github.com/ChurchCRM/CRM/assets/6739256/30ee0177-9cc6-4d65-9d70-c6cfe80d1177)

3. Login to the application (Admin or others) 
4. Navigate to Family page. (https://crm.site/v2/family) and you will get the xss alert. 
![CRMXSS](https://github.com/ChurchCRM/CRM/assets/6739256/4dacc5ac-b432-4db8-951c-e06d26c7adb9)

### Impact 
Stored XSS attacks are even more significant in websites that require authentication. When an authenticated user visits a page with stored XSS, attackers are usually able to hijack their session and perform actions on their behalf. On some websites, such as those of financial or medical institutions, this can result in financial loss or exposure of highly sensitive data.

### Remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:

* Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
* User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (&lt; &gt; etc).



Stored XSS from external family registration 
This is a GitHub Issue
repo:CRM
owner:ChurchCRM
Title : Stored XSS from external family registration 
Issue date:

--- start body ---
### Description

A stored XSS vulnerability has been found in Church CRM when the application default setting is open to register the family without the login. 

- ChurchCRM version: 5.8.0
- ChurchCRM is running with docker.
- PHP version the server running: 8.3.7
- vulnerable parameter : Family Info
- Severity : High
- payload : `"><img src=x onerror=alert(2)>`

### Steps To Reproduce

1. Logout your account and navigate to login page.
![image](https://github.com/ChurchCRM/CRM/assets/6739256/cb8505cf-6f48-450f-9c2e-c863c4862037)

2. Click on Register a new Family and add the payload `"><img src=x onerror=alert(2)>` in Family name text field and register.
![image](https://github.com/ChurchCRM/CRM/assets/6739256/30ee0177-9cc6-4d65-9d70-c6cfe80d1177)

3. Login to the application (Admin or others) 
4. Navigate to Family page. (https://crm.site/v2/family) and you will get the xss alert. 
![CRMXSS](https://github.com/ChurchCRM/CRM/assets/6739256/4dacc5ac-b432-4db8-951c-e06d26c7adb9)

### Impact 
Stored XSS attacks are even more significant in websites that require authentication. When an authenticated user visits a page with stored XSS, attackers are usually able to hijack their session and perform actions on their behalf. On some websites, such as those of financial or medical institutions, this can result in financial loss or exposure of highly sensitive data.

### Remediation
In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:

* Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
* User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (&lt; &gt; etc).



--- end body ---
