The Herd Effects WordPress plugin before 5.2.3 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup)

CVE-2023-4022

The tagDiv Composer WordPress plugin before 4.2, used as a companion by the Newspaper and Newsmag themes from tagDiv, does not have authorisation in a REST route and does not validate as well as escape some parameters when outputting them back, which could allow unauthenticated users to perform Stored Cross-Site Scripting attacks.

CVE-2023-3169

Interact 7.9.79.5 allows stored Cross-site Scripting (XSS) attacks in several locations, allowing an attacker to store a JavaScript payload.

**Abstract Advisory Information**

The feature, to attach a document to a post, is prone to stored Cross-site Scripting (XSS) attacks in several locations allowing an attacker to store a JavaScript payload.

Author: Dominique Righetto

**Version affected**

Name: Interact Software

Versions: 7.9.79.5

**Common Vulnerability Scoring System**

CVSS SCORE 5.4

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

**Patch**

No patch available

**References**

CVE – CVE-2023-41103 (mitre.org)

**Vulnerability Disclosure Timeline**

*   *   20/05/2022: Vulnerability discovery
    *   22/05/2022: Vulnerability Report to CERT-XLM
    *   05/06/2022: Vulnerability Report to Vendor through investigation
    *   05/06/2022: Vulnerability Report to Vendor through investigation
    *   13/06/2022: Vulnerability Report to Vendor through investigation
    *   20/06/2022: Community account creation asked to InteractSoftware to contact their technical departement
    *   20/06/2022: Vulnerability Report to Vendor through investigation
    *   20/06/2022: Urge vendor to reply via twitter
    *   04/07/2023: Update asking to vendor through investigation
    *   04/07/2023: Update asking to vendor for the community account creation
    *   15/07/2023: Ticket for a community account creation closed
    *   17/07/2023: Reply to help@interact-intranet.com asking for an update
    *   19/07/2023: Reply to help@interact-intranet.com asking for an update
    *   01/08/2023: Phonecall to +1 (646) 564 5775, gave vendor information for them to reach us back
    *   01/08/2023: Phonecall to +1 (646) 564 5775
    *   16/08/2023: Phonecall to +1 (646) 564 5775, got redirected to help@interactsoftware.com.
    *   16/08/2023: Update asked to help@interactsoftware.com.
    *   16/08/2023: Request CVE ID to Mitre
    *   23/08/2023: CVE IDs assigned : CVE-2023-41103
    *   24/08/2023: Vulnerabilty disclosure

Our website uses cookies technologies to assist with navigation and your ability to provide feedback, analyze your use of our products and services, to enable you to use the social media functionalities and assist with our promotional and marketing efforts, and provide content from third parties. You may choose to opt-out from all non-essential cookies or allow them for a better browsing experience.  
For more information on the use of cookies, Please check our Privacy Notice ACCEPT REJECT SETTINGS

CVE-2023-41103: CVE-2023-41103 - Excellium Services

Multiple cross-site scripting (XSS) vulnerabilities in Dairy Farm Shop Management System Using PHP and MySQL v1.1 allow attackers to execute arbitrary web scripts and HTML via a crafted payload injected into the Category and Category Field parameters.

In this section, we'll explain what cross-site scripting is, describe the different varieties of cross-site scripting vulnerabilities, and spell out how to find and prevent cross-site scripting.

**What is cross-site scripting (XSS)?**

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform, and to access any of the user's data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application's functionality and data.

**How does XSS work?**

Cross-site scripting works by manipulating a vulnerable web site so that it returns malicious JavaScript to users. When the malicious code executes inside a victim's browser, the attacker can fully compromise their interaction with the application.

**Labs**

If you're already familiar with the basic concepts behind XSS vulnerabilities and just want to practice exploiting them on some realistic, deliberately vulnerable targets, you can access all of the labs in this topic from the link below.

*   View all XSS labs

**XSS proof of concept**

You can confirm most kinds of XSS vulnerability by injecting a payload that causes your own browser to execute some arbitrary JavaScript. It's long been common practice to use the alert() function for this purpose because it's short, harmless, and pretty hard to miss when it's successfully called. In fact, you solve the majority of our XSS labs by invoking alert() in a simulated victim's browser.

Unfortunately, there's a slight hitch if you use Chrome. From version 92 onward (July 20th, 2021), cross-origin iframes are prevented from calling alert(). As these are used to construct some of the more advanced XSS attacks, you'll sometimes need to use an alternative PoC payload. In this scenario, we recommend the print() function. If you're interested in learning more about this change and why we like print(), check out our blog post on the subject.

As the simulated victim in our labs uses Chrome, we've amended the affected labs so that they can also be solved using print(). We've indicated this in the instructions wherever relevant.

**What are the types of XSS attacks?**

There are three main types of XSS attacks. These are:

*   Reflected XSS, where the malicious script comes from the current HTTP request.
*   Stored XSS, where the malicious script comes from the website's database.
*   DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.

**Reflected cross-site scripting**

Reflected XSS is the simplest variety of cross-site scripting. It arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.

Here is a simple example of a reflected XSS vulnerability:

https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>

The application doesn't perform any other processing of the data, so an attacker can easily construct an attack like this:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>

If the user visits the URL constructed by the attacker, then the attacker's script executes in the user's browser, in the context of that user's session with the application. At that point, the script can carry out any action, and retrieve any data, to which the user has access.

**Stored cross-site scripting**

Stored XSS (also known as persistent or second-order XSS) arises when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.

The data in question might be submitted to the application via HTTP requests; for example, comments on a blog post, user nicknames in a chat room, or contact details on a customer order. In other cases, the data might arrive from other untrusted sources; for example, a webmail application displaying messages received over SMTP, a marketing application displaying social media posts, or a network monitoring application displaying packet data from network traffic.

Here is a simple example of a stored XSS vulnerability. A message board application lets users submit messages, which are displayed to other users:

<p>Hello, this is my message!</p>

The application doesn't perform any other processing of the data, so an attacker can easily send a message that attacks other users:

<p><script>/* Bad stuff here... */</script></p>

**DOM-based cross-site scripting**

DOM-based XSS (also known as DOM XSS) arises when an application contains some client-side JavaScript that processes data from an untrusted source in an unsafe way, usually by writing the data back to the DOM.

In the following example, an application uses some JavaScript to read the value from an input field and write that value to an element within the HTML:

var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

If the attacker can control the value of the input field, they can easily construct a malicious value that causes their own script to execute:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

In a typical case, the input field would be populated from part of the HTTP request, such as a URL query string parameter, allowing the attacker to deliver an attack using a malicious URL, in the same manner as reflected XSS.

**What can XSS be used for?**

An attacker who exploits a cross-site scripting vulnerability is typically able to:

*   Impersonate or masquerade as the victim user.
*   Carry out any action that the user is able to perform.
*   Read any data that the user is able to access.
*   Capture the user's login credentials.
*   Perform virtual defacement of the web site.
*   Inject trojan functionality into the web site.

**Impact of XSS vulnerabilities**

The actual impact of an XSS attack generally depends on the nature of the application, its functionality and data, and the status of the compromised user. For example:

*   In a brochureware application, where all users are anonymous and all information is public, the impact will often be minimal.
*   In an application holding sensitive data, such as banking transactions, emails, or healthcare records, the impact will usually be serious.
*   If the compromised user has elevated privileges within the application, then the impact will generally be critical, allowing the attacker to take full control of the vulnerable application and compromise all users and their data.

**How to find and test for XSS vulnerabilities**

The vast majority of XSS vulnerabilities can be found quickly and reliably using Burp Suite's web vulnerability scanner.

Manually testing for reflected and stored XSS normally involves submitting some simple unique input (such as a short alphanumeric string) into every entry point in the application, identifying every location where the submitted input is returned in HTTP responses, and testing each location individually to determine whether suitably crafted input can be used to execute arbitrary JavaScript. In this way, you can determine the context in which the XSS occurs and select a suitable payload to exploit it.

Manually testing for DOM-based XSS arising from URL parameters involves a similar process: placing some simple unique input in the parameter, using the browser's developer tools to search the DOM for this input, and testing each location to determine whether it is exploitable. However, other types of DOM XSS are harder to detect. To find DOM-based vulnerabilities in non-URL-based input (such as document.cookie) or non-HTML-based sinks (like setTimeout), there is no substitute for reviewing JavaScript code, which can be extremely time-consuming. Burp Suite's web vulnerability scanner combines static and dynamic analysis of JavaScript to reliably automate the detection of DOM-based vulnerabilities.

**Content security policy**

Content security policy (CSP) is a browser mechanism that aims to mitigate the impact of cross-site scripting and some other vulnerabilities. If an application that employs CSP contains XSS-like behavior, then the CSP might hinder or prevent exploitation of the vulnerability. Often, the CSP can be circumvented to enable exploitation of the underlying vulnerability.

**Dangling markup injection**

Dangling markup injection is a technique that can be used to capture data cross-domain in situations where a full cross-site scripting exploit is not possible, due to input filters or other defenses. It can often be exploited to capture sensitive information that is visible to other users, including CSRF tokens that can be used to perform unauthorized actions on behalf of the user.

**How to prevent XSS attacks**

Preventing cross-site scripting is trivial in some cases but can be much harder depending on the complexity of the application and the ways it handles user-controllable data.

In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:

*   **Filter input on arrival.** At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
*   **Encode data on output.** At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
*   **Use appropriate response headers.** To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
*   **Content Security Policy.** As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.

**Common questions about cross-site scripting**

**How common are XSS vulnerabilities?** XSS vulnerabilities are very common, and XSS is probably the most frequently occurring web security vulnerability.

**How common are XSS attacks?** It is difficult to get reliable data about real-world XSS attacks, but it is probably less frequently exploited than other vulnerabilities.

**What is the difference between XSS and CSRF?** XSS involves causing a web site to return malicious JavaScript, while CSRF involves inducing a victim user to perform actions they do not intend to do.

**What is the difference between XSS and SQL injection?** XSS is a client-side vulnerability that targets other application users, while SQL injection is a server-side vulnerability that targets the application's database.

**How do I prevent XSS in PHP?** Filter your inputs with a whitelist of allowed characters and use type hints or type casting. Escape your outputs with htmlentities and ENT_QUOTES for HTML contexts, or JavaScript Unicode escapes for JavaScript contexts.

**How do I prevent XSS in Java?** Filter your inputs with a whitelist of allowed characters and use a library such as Google Guava to HTML-encode your output for HTML contexts, or use JavaScript Unicode escapes for JavaScript contexts.

CVE-2023-41593: What is cross-site scripting (XSS) and how to prevent it? | Web Security Academy

Cross Site Scripting vulnerability in ZLMediaKiet v.4.0 and v.5.0 allows an attacker to execute arbitrary code via a crafted script to the URL.

CVE-2023-39067

WordPress Slimstat Analytics plugin versions 5.0.9 and below suffer from cross site scripting and remote SQL injection vulnerabilities.

    Vulnerability Summary from Wordfence IntelligenceDescription: Slimstat Analytics <= 5.0.9 – Authenticated (Contributor+) Stored Cross-Site Scripting via Shortcode Affected Plugin: Slimstat AnalyticsPlugin Slug: wp-slimstatAffected Versions: <= 5.0.9CVE ID: CVE-2023-4597CVSS Score: 6.4 (Medium)CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:NResearcher/s: Lana Codes Fully Patched Version: 5.0.10The Slimstat Analytics plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘slimstat’ shortcode in versions up to, and including, 5.0.9 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.Description: Slimstat Analytics <= 5.0.9 – Authenticated (Contributor+) Blind SQL Injection via Shortcode Affected Plugin: Slimstat AnalyticsPlugin Slug: wp-slimstatAffected Versions: <= 5.0.9CVE ID: CVE-2023-4598CVSS Score: 8.8 (High)CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HResearcher/s: Lana Codes Fully Patched Version: 5.0.10The Slimstat Analytics plugin for WordPress is vulnerable to SQL Injection via the plugin’s shortcode in versions up to, and including, 5.0.9 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers with contributor-level and above permissions to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.Technical AnalysisSlimstat Analytics is a WordPress website traffic analytics plugin that offers several features for analyzing and monitoring traffic. It provides a shortcode ([slimstat]) that displays various types of statistics when added to a WordPress page or post.Unfortunately, insecure implementation of the plugin’s shortcode functionality allows for the injection of arbitrary web scripts into these pages. Examining the code reveals that the shortcode has several types based on the ‘f’ parameter. In vulnerable versions, the ‘top-all’ type does not adequately sanitize the user-supplied ‘w’ attribute, and then fails to escape the ‘class’ output derived from the ‘w’ parameter when it displays the statistics. This makes it possible to inject attribute-based Cross-Site Scripting payloads via the ‘w’ attribute.[View this code snippet on the blog.] This makes it possible for threat actors with contributor-level access to a site to carry out stored XSS attacks. Once a script is injected into a page or post, it will execute each time a user accesses the affected page. While this vulnerability does require that a trusted contributor account is compromised, or that a user be able to register as a contributor, successful threat actors could steal sensitive information, manipulate site content, inject administrative users, edit files, or redirect users to malicious websites which are all severe consequences.Further examining the code, we also found a SQL Injection vulnerability within the same shortcode. Although the ‘w’ parameter will be converted into an array, it is not properly sanitized. This parameter is used for the column in the database query, and although the prepare function is used, the column is not specified as a placeholder, which makes it possible for an attacker to perform SQL injection attacks.[View this code snippet on the blog.] Since no data from the SQL query was returned in the response, an attacker would need to use a Time-Based blind approach to extract information from the database. This means that they would need to use SQL CASE statements along with the SLEEP() command while observing the response time of each request to steal information from the database. This is an intricate, yet frequently successful method to obtain information from a database when exploiting SQL Injection vulnerabilities.Disclosure TimelineAugust 24, 2023 – Wordfence Threat Intelligence team discovers the stored XSS and SQL Injection vulnerabilities in Slimstat Analytics.August 24, 2023 – We initiate contact with the plugin vendor asking that they confirm the inbox for handling the discussion.August 26, 2023 – The vendor confirms the inbox for handling the discussion.August 26, 2023 – We send over the full disclosure details for the XSS vulnerability.August 27, 2023 – We send over the full disclosure details for the SQL injection vulnerability.August 27, 2023 – The vendor acknowledges the report and begins working on a fix.August 28, 2023 – The fully patched version, 5.0.10, is released.ConclusionIn this blog post, we have detailed stored XSS and SQL Injection vulnerabilities within the Slimstat Analytics plugin affecting versions 5.0.9 and earlier. This vulnerability allows authenticated threat actors with contributor-level permissions or higher to inject malicious web scripts into pages that execute when a user accesses an affected page, and extract sensitive information from a database. These vulnerabilities have been fully addressed in version 5.0.10 of the plugin.We encourage WordPress users to verify that their sites are updated to the latest patched version of Slimstat Analytics.All Wordfence users, including those running Wordfence Premium, Wordfence Care, and Wordfence Response, as well as sites still running the free version of Wordfence, are fully protected against this vulnerability.If you know someone who uses this plugin on their site, we recommend sharing this advisory with them to ensure their site remains secure, as this vulnerability poses a significant risk.For security researchers looking to disclose vulnerabilities responsibly and obtain a CVE ID, you can submit your findings to Wordfence Intelligence and potentially earn a spot on our leaderboard.

WordPress Slimstat Analytics 5.0.9 Cross Site Scripting / SQL Injection

IWT Imagine CMS version 1.0 suffers from a cross site scripting vulnerability.

    ====================================================================================================================================| # Title     : IWT Imagineِ CMS v1.0 XSS Vulnerability                                                                             || # Author    : indoushka                                                                                                          || # Tested on : windows 10 Français V.(Pro) / browser : Mozilla firefox 66.0.2(32-bit)                                             | | # Vendor    : http://imaginewebtech.com                                                                                          |  ====================================================================================================================================poc :[+] Dorking İn Google Or Other Search Enggine.[+] Use payload : /photo-gallery.html?id=1'<marquee><font color=lime size=32>Hacked by indoushka</font></marquee>[+] https://127.0.0.1wwsanklechain/photo-gallery.html?id=1%27%3Cmarquee%3E%3Cfont%20color=lime%20size=32%3EHacked%20by%20indoushka%3C/font%3E%3C/marquee%3EGreetings to :=========================================================================================================================jericho * Larry W. Cashdollar * brutelogic* shadow_00715 *9aylas*djroot.dz*LiquidWorm*Hussin-X*D4NB4R *ViRuS_Ra3cH *yasMouh* CraCkEr  |=======================================================================================================================================

IWT Imagine CMS 1.0 Cross Site Scripting

HKcms v2.3.0.230709 is vulnerable to Cross Site Scripting (XSS) allowing administrator cookies to be stolen.

**HkCms是否会收取授权费用？**

HkCms免费开源，无需授权，永久商用，在您遵守《HkCms软件许可使用协议》下可将HkCms开源内容管理系统用于商业。

从ShuipFCms到LvYeCms，再到HkCms，我们从未停下为建站行业提供优秀的免费开源内容管理系统的初心，我们希望将免费开源进行到底。

各位网友务必在遵守国家法律法规的前提下使用HkCms开源内容管理系统，禁止使用HkCms开源内容管理系统进行任何违法犯罪的活动，使用HkCms开源内容管理系统过程中产生的任何版权纠纷及法律责任由使用方承担。

一个优秀的开源内容管理系统离不开网友的建议、帮助和支持，我们希望与广大网友一起完善我们的开源内容管理系统，在使用过程中有任何的建议和思路都可以通过QQ群：808251031 向我们反馈。

版本号：HkCms\_v2.3.0.230709

*   提示： 1. 本次升级会更改到数据库，升级前，请备份好站点(请备份好站点、请备份好站点、请备份好站点)。 2. 本次升级大范围覆盖请备份好修改的模板。 3. 手动升级参考：https://www.hkcms.cn/help/azbs/167.html 4. 若你调整过HkCms代码，请不要升级 5. 升级遇到问题请Q群(808251031)、联系技术QQ:746117169 【新增】 采用新的多语言维护界面 【新增】 lang标签用于指定语言下才显示内容 【调整】 调整内容多语言同步机制 【调整】 调整默认编辑器宽度问题 【调整】 多语言获取标签调整 【调整】 前台多语言列表调整 【调整】 ThinkPHP核心升级到V6.1.3
*   【优化】 优化后台复选框组件 【优化】 优化应用中心账号获取方式 【优化】 多语言同步优化
*   【修复】 修复前台无法权限控制问题 【修复】 修复会员管理启用禁用异常问题 【修复】 修复数字组件在内容管理添加时无法保存小数 【修复】 修复留言表单无法删除问题 【修复】 修复静态生成验证码无法显示问题 【修复】 修复栏目管理新增可能出现parent\_id不存在问题 【修复】 修复同步多语言时栏目管理有上下级时未能正常同步 【修复】 修复index\_url方法在静态生成时无法正常隐藏入口文件 【修复】 修复静态生成的留言表单地址不对 【修复】 修复静态生成验证码地址异常问题 【修复】 修复静态生成列表内容下一页多语言情况下页码不对问题 【修复】 修复会员组无法修复权限规则问题 【修复】 修复会员无法修改头像问题

升级包(包含补丁)

**补丁1：230712 下载**

提示：

1).本次升级不会改到数据库

**1\. 升级内容**

【修复】修复内容管理无法正常显示栏目

【修复】修复语言列表新增到其他语言未能同步

【修复】修复语言列表时间显示问题

【修复】修复安装无法显示正常的演示数据

**2\. 升级会覆盖以下文件**

app/admin/controller/BaseController.php

app/admin/controller/routine/Lang.php

app/common/model/lang/Lang.php

app/install/Index.php

config/ver.php

**补丁2：230726 下载**

提示：

1).本次升级不会改到数据库

**1\. 升级内容**

【修复】 修复搜索页提交参数不对

【新增】 支持复制模型时主表的部分字段属性支持复制

【修复】 修复模型字段 发布时间 不能正常修改问题

【修复】 修改模板配置立即生效

【修复】 修复复制或移动文章部分栏目不能正常显示

【调整】 调整内容管理文章操作更新缓存

**2\. 升级会覆盖以下文件**

app/admin/controller/cms/Model.php

app/admin/controller/Appcenter.php

app/admin/controller/cms/Archives.php

app/admin/controller/cms/Single.php

app/admin/model/cms/Archives.php

app/admin/model/cms/Single.php

app/api/controller/Ems.php

app/api/lang/zh-cn.php

app/common/services/cache/CacheService.php

app/common/services/cms/ArchivesService.php

extend/libs/table/TableOperate.php

config/ver.php

**补丁3：230813 下载**

提示：

本次升级不会更改到数据库。

**1\. 升级内容**

【修复】 XSS漏洞修复

【修复】 修复主题切换缓存问题

【修复】 修复附件管理ICO格式图片不显示问题

【修复】 修复模型文件字段选择文件异常

**2\. 升级会覆盖以下文件**

app/admin/model/auth/AdminLog.php

app/admin/controller/Appcenter.php

template/admin/adminlte/routine/attachment/select.html

public/static/common/js/table.js

config/ver.php

版本号：HkCms\_v2.2.4.230206

*   提示： 1. 本次升级会更改到数据库，升级前，请备份好站点(请备份好站点、请备份好站点、请备份好站点)。 2. 本次升级会重置URL伪静态，如果你更改过，升级后需要重新设置。 3. 若你安装了会员中心与TAG标签插件，请卸载后再升级。 4. 本地升级不会覆盖模板与插件。 5. 手动升级参考：https://www.hkcms.cn/help/azbs/167.html 6. 升级遇到问题请Q群(808251031)联系技术 【新增】 默认集成TAG标签功能，无需安装TAG插件。 【新增】 默认集成会员中心 【新增】 内容页面支持标签内链、标签管理支持多语言 【新增】 字符截取标签支持不同语言截取不同的字符长度 【调整】 全局不设置过滤函数，有需要的在\\app\\Request.php 中设置 【调整】 ThinkPHP核心升级到v6.1.1版本
*   【优化】 优化内容分页 【优化】 取消限制内容字段标题 【优化】 优化填写手机域名后的判断 【优化】 优化字段配置格式 【优化】 优化留言表单邮箱提示 【优化】 调整多语言检测机制 【优化】 优化多应用访问绑定机制 【优化】 优化默认模板 【优化】 content标签增加field字段，可控制只查询特定的字段列表，提高查询速度 【优化】 优化整站源码导出 【优化】 优化缓存机制 【优化】 优化后台管理界面 【优化】 优化为env文件开启调试模式优先级高于后台控制
*   【修复】 修正内容管理栏目排序异常 【修复】 修复模型字段可能无法修改问题 【修复】 修复标签单条获取 【修复】 修复文件大小获取异常 【修复】 修复留言表单无法访问问题 【修复】 修复本地导入模板可能导致的异常 【修复】 修复静态生成可能造成的异常 【修复】 修复动态下拉时间类型可能出现的异常 【修复】 修复自定义URL时点击量无法加1 【修复】 修复文件下载异常 【修复】 修复模板配置文件异常问题

升级包(包含补丁)

**补丁1：230313 下载**

提示：

1）本次升级不会更改到数据库。

1\. 升级内容

【优化】模板文件获取缓存优化  

【修复】修复日志排序  

【修复】修复没有副表字段时无法添加问题  

【修复】修复子管理员栏目权限获取异常  

2\. 升级会覆盖以下文件

app/admin/controller/cms/Category.php

app/admin/controller/cms/Archives.php

app/admin/model/cms/ModelFieldBind.php

template/admin/adminlte/auth/adminlog/index.html

app/common.php

config/ver.php

**补丁2：230328 下载**

提示：

本次升级不会更改到数据库。

1\. 升级内容

【优化】 优化内容管理列表有置顶属性时可修改排序

【优化】 优化模板列表缓存

【修复】 修复标签管理数据统计问题

【修复】 修复取消水印重新上传同图片无法更新问题

【修复】 修复删除没有日志记录问题

【修复】 修复会员管理模块的异常

【修复】 前台列表筛选修复多选组件下无法筛选出来的问题

【调整】 整站源码发布到应用中心规则调整

2\. 升级会覆盖以下文件

app/admin/controller/Appcenter.php

app/admin/controller/Tags.php

app/common/library/Upload.php

app/admin/model/cms/Archives.php

app/admin/controller/cms/ModelField.php

app/admin/controller/user/Group.php

app/admin/controller/user/User.php

app/admin/validate/user/UserGroup.php

public/static/common/js/table.js

config/ver.php

版本号：HkCms\_v2.2.3

*   提示：本次版本改动较大，数据库有较大的调整，所以暂不支持HkCms\_v2.2.2版本以及之前版本升级到本次版本。 1. 升级内容 【新增】 键值对数组组件新增默认模板配置，方便快速录入 【新增】 栏目标签支持获取多个指定的栏目 【新增】 新增文档链接跳转外链 【新增】 文档自定义URL别名 【新增】 搜索页新增搜索字符高亮显示 【新增】 内容标签支持多个栏目ID 【新增】 内容标签支持指定多个文档ID，指定单个文档ID 【新增】 内容标签列表默认有副表字段 【新增】 文档标题支持加粗与设置颜色 【新增】 新增文章支持副栏目 【新增】 采用全新的模型主表
*   【优化】 加强应用中心记住密码的安全性 【优化】 数据排序类型统一 【优化】 优化栏目管理上下级显示 【优化】 优化后台界面样式 【优化】 优化content标签的id条件 【优化】 优化模板升级检测 【优化】 优化本地模板读取 【优化】 优化插件js加载
*   【修复】 修复单页栏目删除后同步删除文档 【修复】 修复前台多语言切换可能失效问题 【修复】 修复模板输出替换配置不被覆盖 【修复】 修复后台菜单可能失效无法点击问题 【修复】 修复后台JS引用 【修复】 修复php think run 无法使用问题 【修复】 修复界面在火狐浏览器兼容问题 【修复】 修复单页模型第一次添加为空访问报错问题，调整为创建栏目自动生成单页数据 【修复】 修复栏目管理页面添加子栏目时模型不对 【修复】 修复栏目更改未能立即生效前台 【修复】 修复标签关闭执行多次问题 【修复】 站点模块文字链接无法拖动 【修复】 修复角色修改下拉组件异常 【修复】 修复非多语言情况下静态生成异常 【修复】 修复PHP8.0下某些异常

**补丁1：221012 下载**

提示：本次更新针对HkCms\_v2.2.3.220920版本的修复，修复将更改数据库category表weigh字段

1\. 升级内容

【修复】 修复栏目管理添加其他链接报错

【修复】 修复站点配置手动输入应用中心账号异常

【修复】 修复SEO生成静态报错

【修复】修复category表weigh字段

2\. 升级会覆盖以下文件

app/admin/controller/cms/Category.php

app/admin/controller/routine/Config.php

app/admin/controller/routine/Seo.php

app/admin/model/cms/Category.php

app/admin/library/Html.php

app/admin/lang/zh-cn/appcenter.php

app/index/model/cms/Category.php

**补丁2：221017 下载**

提示：

1）升级过程中弹出框会遮挡确认升级提示，将弹出框往两边移动即可看到确认升级提示。

2）本次升级不会更改到数据库。

1\. 升级内容

【优化】 HkCms升级页面优化

【优化】 优化创建菜单排序

【修复】 模型字段主表字段无法修改问题

【修复】 修复远程下载异常

【修复】 修复伪静态下部分页面显示index.php问题

【修复】 修复其他已知问题

2\. 升级会覆盖以下文件

app/admin/controller/routine/Attachment.php

app/admin/controller/cms/Category.php

app/admin/controller/cms/ModelField.php

app/admin/model/auth/AuthRule.php

app/admin/model/cms/ModelField.php

app/admin/lang/zh-cn/cms/modelfield.php

app/admin/validate/cms/ModelField.php

app/index/controller/Index.php

app/index/route/route.php

app/common/library/Url.php

template/admin/adminlte/appcenter/local.html

template/admin/adminlte/index/dashboard.html

public/static/module/admin/adminlte/css/adminlte.css

public/static/common/js/table.js

config/ver.php

**补丁3：221019 下载**

提示：

1）本次升级不会更改到数据库。

1\. 升级内容

【修复】 修复publish\_time字段异常

【修复】 修复验证码异常

2\. 升级会覆盖以下文件

app/admin/controller/cms/Single.php

app/admin/model/cms/Archives.php

app/admin/model/cms/Single.php

app/api/controller/Ems.php

app/index/controller/Guestbook.php

extend/libs/captcha/Captcha.php

template/admin/adminlte/index/dashboard.html

config/ver.php

**补丁4：221021 下载**

提示：

1）本次升级不会更改到数据库。

1\. 升级内容

【优化】 优化后台https访问时可能导致上传无法正常使用

【修复】 修复多语言在mysql8.0的情况显示异常

【修复】 修复channel标签中的istotal参数异常

【修复】 修复catid栏目不存在时异常

【修复】 修复位置选取插件无法选取问题  

【修复】 修复其他已知的问题

2\. 升级会覆盖以下文件

addons/address/install/static/address.js

app/admin/controller/BaseController.php

app/admin/controller/routine/Config.php

app/admin/model/routine/Config.php

app/index/taglib/hkcms/TagContent.php

template/admin/adminlte/routine/config/index.html

public/static/addons/address/address.js

public/static/common/js/form.js

public/static/common/js/hkcms.js

public/static/common/js/table.js

app/common.php

config/ver.php

CVE-2023-40786: HkCms版本更新说明、HkCms版本列表、HkCms升级日志 – HkCms开源内容管理系统

With the growing reliance on web applications and digital platforms, the use of application programming interfaces (APIs) has become increasingly popular. If you aren’t familiar with the term, APIs allow applications to communicate with each other and they play a vital role in modern software development.
However, the rise of API use has also led to an increase in the number of API breaches.

With the growing reliance on web applications and digital platforms, the use of application programming interfaces (APIs) has become increasingly popular. If you aren't familiar with the term, APIs allow applications to communicate with each other and they play a vital role in modern software development.

However, the rise of API use has also led to an increase in the number of API breaches. These breaches occur when unauthorized individuals or systems gain access to an API and the data it contains. And as victims can attest, breaches can have devastating consequences for both businesses and individuals.

One of the primary concerns with API breaches is the exposure of sensitive data. APIs often contain or provide access to personal or financial information, and if this data falls into the wrong hands, it can be used for fraudulent activities or identity theft.

API breaches can also lead to severe reputational damage for businesses. Customers and stakeholders expect their information to be protected, and a breach can result in an irreparable loss of trust, which often results in customers taking their business elsewhere.

For these reasons, it's essential to implement robust security measures to protect your APIs, and the data traversing them, to prevent breaches from occurring. With that said, this blog will cover some of the most important security measures you can take to prevent API breaches, as well as provide resources for additional learning.

**Best practices for API security**

While APIs offer many benefits, they also pose significant security risks. API security is crucial in protecting sensitive data and ensuring that only authorized users have access to it. Without proper security measures in place, APIs can be vulnerable to attacks such as SQL injection or business logic manipulation.

Therefore, it's important to implement proper API security measures. Controls such as authentication, authorization, encryption, and secure design ensure that the API is protected from potential threats. Let's take a closer look at what each control is and what it's responsible for.

**Authentication and Authorization**

Authentication and authorization are critical components of API security. Authentication is the process of verifying the identity of a user or application that is requesting access to an API. Authorization is the process of determining what actions a user or application is allowed to perform on the API. API keys and tokens, OAuth and OpenID Connect, and role-based access control are some of the best practices for authentication and authorization in APIs.

*   **API keys and tokens:** API keys and tokens are unique identifiers that are used to authenticate and authorize access to an API. API keys and tokens should be generated securely and should be kept confidential. They should also be rotated periodically to prevent misuse.
*   **OAuth and OpenID Connect:** OAuth and OpenID Connect are industry-standard protocols for authorization and authentication. OAuth allows users to grant access to their resources without sharing their credentials, while OpenID Connect allows users to authenticate with an identity provider and obtain an ID token that can be used to access APIs. These protocols provide a secure and standardized way of managing access to APIs.
*   **Role-based access control:** Role-based access control is a method of controlling access to APIs based on the roles assigned to users or applications. This approach allows administrators to define different levels of access to APIs based on the needs of different users or applications.

**Data Encryption**

Data encryption is the process of encoding data so that it can only be read by authorized parties. Encryption is essential for protecting sensitive data that is transmitted over APIs.

*   **SSL/TLS certificates:** SSL/TLS certificates are used to encrypt data in transit between clients and servers. These certificates are issued by trusted third-party certificate authorities and provide a secure way of transmitting data over APIs.
*   **Transport Layer Security:** Transport Layer Security (TLS) is a protocol that provides encryption and authentication for data transmitted over APIs. TLS is widely used to protect sensitive data transmitted over the internet and is a critical component of API security.
*   **Encryption of data at rest:** Encryption of data at rest is the process of encrypting data that is stored on servers. This approach protects data from unauthorized access in case of a data breach. It is important to choose strong encryption algorithms and to manage encryption keys securely.

**API Design and Implementation**

API design and implementation also play a critical role in API security. Developers should follow best practices for versioning, input validation and data sanitization, and API endpoint security.

*   **Versioning:** Versioning is the process of managing changes to APIs over time. Developers should use versioning to ensure that changes to APIs don't break existing client applications. They should also communicate changes to APIs to clients and provide backward compatibility when possible.
*   **Input validation and data sanitization:** Input validation is the process of ensuring that data received by an API is valid and meets the expected format. Data sanitization is the process of removing any malicious or harmful data from API requests. Developers should implement input validation and data sanitization to prevent attacks such as SQL injection and cross-site scripting.
*   **API endpoint security:** API endpoint security is the process of securing API endpoints from unauthorized access. Developers should use authentication and authorization to control access to API endpoints. They should also implement rate limiting to prevent denial of service attacks.

**Testing and monitoring your API**

Testing and monitoring your API is essential for ensuring that it works correctly and reliably. Automated testing, manual testing, and API monitoring are critical aspects of API development that you should not overlook. By performing these tests early and monitoring your APIs often, you can identify potential issues early in the development process and take corrective actions to ensure that your APIs are secure and reliable.

**Automated Testing**

Automated testing is an essential part of API development. There are different types of automated testing that you can perform on your API, including:

*   **Unit Testing:** Unit testing is the process of testing individual units or components of your API to ensure that they work correctly. Unit testing is essential for detecting and fixing bugs early in the development process. Unit tests are usually written by developers and are executed automatically every time changes are made to the API code.
*   **Integration Testing:** Integration testing involves testing how different components of your API work together. It's essential to ensure that different components of your API can work together without any issues. Integration tests are usually automated and they're executed after unit tests.
*   **Functional Testing:** Functional testing involves testing the functionality of your API. It's essential to ensure that your API works as intended and provides the expected results. Functional tests are usually automated and they are executed after integration tests.
*   **Continuous Automated Red Teaming (CART):** CART is a security testing methodology that involves the automated and continuous execution of simulated attacks against APIs. It provides organizations with a proactive approach to security by simulating real-world attacks and allowing them to remediate vulnerabilities before they can be exploited by malicious actors.

**Manual Testing**

Manual testing can be another important aspect of API development. There are different types of manual testing that you can perform on your API, including:

*   **Penetration Testing:** Penetration testing involves testing your API for vulnerabilities. It's essential to ensure that your API is secure and cannot be exploited by attackers. Penetration testing is usually performed by security experts who try to hack into your API to identify vulnerabilities.
*   **Threat Modeling:** Threat modeling involves identifying potential security threats and vulnerabilities in your API. It's essential to understand the potential threats and vulnerabilities in your API and take steps to mitigate them.
*   **Code Review:** Code review involves reviewing your API code to ensure that it is of high quality and meets the best practices. Code review is essential for detecting and fixing bugs and improving the overall quality of your API code.

**API Monitoring**

API monitoring is crucial for ensuring that your API is running correctly and reliably. There are different types of API monitoring that you can perform, including:

*   **Logs and Analytics:** Logs and analytics allow you to monitor your API's performance and identify issues quickly. You can use software tools to collect and analyze logs and other data to identify potential issues and take corrective actions.
*   **Alerts and Notifications:** Alerts and notifications allow you to receive real-time notifications when issues occur with your API. You can configure alerts and notifications to notify you via email, text message, or other methods when issues occur.
*   **Continuous Monitoring:** Continuous monitoring involves monitoring your API continuously to ensure that it is running correctly and reliably. You can use software tools to monitor your API's performance and identify potential issues proactively.

**Automating your API security**

Preventing API breaches can sound like a real feat. And to be honest, it is without the right tools. Businesses need to prioritize API security to protect their data and applications. Which means investing in a comprehensive API security platform that automates all of the aforementioned capabilities and features. This includes API discovery, posture management, runtime protection, and API security testing.

The platform should also integrate with a range of software development tools, allowing developers to incorporate security testing into their development process. This integration ensures that security is an integral part of the software development lifecycle. Let's get a quick look at what comprehensive API security entails:

**API Discovery**

API discovery is the process of automatically identifying APIs across your organization's network and cloud environments. This helps businesses understand the scope of their API environment and identify any security vulnerabilities that may have been overlooked.

**Posture Management**

Posture management enables businesses to understand the scope of their API environment and identify any security vulnerabilities that may have been overlooked. This includes classifying sensitive data to ensure regulatory compliance is being adhered to.

**Runtime Protection**

Runtime protection monitors API traffic in real-time, identifying and blocking any suspicious activity. This feature uses machine learning algorithms to detect and prevent attacks such as SQL injections, cross-site scripting, and API scraping.

**API Security Testing**

API security testing feature allows businesses to test their APIs for vulnerabilities and security risks. This feature provides automated scans that simulate attacks on APIs, identifying any security vulnerabilities.

If you're looking for more in-depth guidance on securing your APIs against malicious attacks, be sure to download our latest ebook, **_How to Prevent an API Breach_**_._ This comprehensive guide covers everything you need to prepare your internal teams and systems for thwarting API breaches.

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

How to Prevent API Breaches: A Guide to Robust Security

Cross-site Scripting (XSS) - Stored in GitHub repository instantsoft/icms2 prior to 2.16.1.-git.

Expand Up @@ -292,7 +292,7 @@ public function uploadForm($filename, $allowed\_size = 0, $destination = false) { $dest\_size = (int) $\_FILES\[$filename\]\['size'\]; $dest\_name = files\_sanitize\_name($\_FILES\[$filename\]\['name'\]);  
$file = new cmsUploadfile($source, $this\->allowed\_mime); $file = cmsUploadfile::fromPath($source, $this\->allowed\_mime);  
if (!$file\->isAllowed()) { return \[ Expand Down Expand Up @@ -341,12 +341,12 @@ public function uploadFromLink($post\_filename, $allowed\_size = 0, $destination =  
$link = $file\_name = trim($\_POST\[$post\_filename\]);  
$url\_data = parse\_url($link);  
// Валидный URL с PATH if ( // Валидный URL с PATH filter\_var($link, FILTER\_VALIDATE\_URL, FILTER\_FLAG\_PATH\_REQUIRED) !== $link || // По IP адресу не разрешаем preg\_match('#^(?:(?:https?):\\/\\/)(\[0-9\]{1,3}\\.\[0-9\]{1,3}\\.\[0-9\]{1,3}\\.\[0-9\]{1,3}).\*#ui', $link) empty($url\_data\['host'\]) ) {  
return \[ Expand All @@ -357,6 +357,32 @@ public function uploadFromLink($post\_filename, $allowed\_size = 0, $destination = \]; }  
// Узнаём ipv4 адрес хоста, gethostbyname умеет только ipv4 $host\_ip = gethostbyname($url\_data\['host'\]); // Не зарезольвили if ($host\_ip === $url\_data\['host'\]) { return \[ 'success' => false, 'error' => 'Not allowed', 'name' => '', 'path' => '' \]; }  
// Проверяем вхождение в зарезервированные сети if(filter\_var( $host\_ip, FILTER\_VALIDATE\_IP, FILTER\_FLAG\_IPV4 | FILTER\_FLAG\_NO\_PRIV\_RANGE | FILTER\_FLAG\_NO\_RES\_RANGE ) !== $host\_ip){ return \[ 'success' => false, 'error' => 'Not allowed', 'name' => '', 'path' => '' \]; }  
// проверяем редирект и имя файла $curl = curl\_init(); curl\_setopt($curl, CURLOPT\_PROTOCOLS, CURLPROTO\_HTTPS | CURLPROTO\_HTTP); Expand All @@ -374,8 +400,7 @@ public function uploadFromLink($post\_filename, $allowed\_size = 0, $destination = $url = trim($matches\[1\]);  
if (strpos($url, 'http') !== 0) { $url\_data = parse\_url($link); $link = $url\_data\['scheme'\] . '://' . $url\_data\['host'\] . $url; $link = $url\_data\['scheme'\] . '://' . $url\_data\['host'\] . $url; } else { $link = $url; } Expand Down Expand Up @@ -442,7 +467,7 @@ public function uploadXHR($filename, $allowed\_size = 0, $destination = false) { \*/ private function saveFileFromString($file\_bin, $allowed\_size, $destination, $dest\_name) {  
$file = new cmsUploadfile($file\_bin, $this\->allowed\_mime); $file = cmsUploadfile::fromString($file\_bin, $this\->allowed\_mime);  
if (!$file\->isAllowed()) { return \[ Expand Down

Tag

#xss