By Owais Sultan
Application testing is a process that helps ensure the quality and safety of your software applications, whether the…
This is a post from HackRead.com Read the original post: How SAST Will Improve Your Overall Security: Intro

Application testing is a process that helps ensure the quality and safety of your software applications, whether the app is for a mobile or desktop device. Of course, it’s easy to understand why assessing & inspecting the security of an application can be beneficial. The process of testing can be used to find bugs and vulnerabilities, as well as to evaluate the overall security health of an application.

There are various types of testing that can be performed on an application, and the most popular ones are SAST, DAST, and IAST, but Static Application Security Testing (SAST) is one of the most effective ones.

Namely, SAST is a type of testing that analyzes an application’s source code rather than its binaries or executables. Many online security platforms like Mend SAST allow for an in-depth analysis of the application and can often find vulnerabilities that would otherwise be missed with other methods of testing.

**What is SAST?**

As we mentioned previously, SAST (Static Application Security Testing) is a type of security testing that analyzes your source code for vulnerabilities. This is in contrast to other forms of security testing, which focus on analyzing the behavior of running applications.

Regarding SAST, the method of testing can be used to find a wide variety of security issues, including SQL injection flaws, cross-site scripting (XSS) vulnerabilities, and unsafe coding practices that could lead to buffer overflows or attacks.

Thus, most experts believe that SAST is an important part of any security program, as it can help find vulnerabilities that other types of testing might miss. For example, a web application firewall (WAF) will only be able to detect and block SQL injection attacks if the attacker uses a specific type of payload that the WAF is configured to look for. However, SAST can find SQL injection flaws regardless of the payload that is used, as it analyzes the source code to look for insecure coding practices.

**Comparing SAST with IAST and DAST**

As we mentioned above, SAST is one of three main types of application security testing. The other two are Interactive Application Security Testing (IAST) and Dynamic Application Security Testing (DAST).

In its approach, IAST is similar to SAST in that it also analyzes the source code of an application. However, IAST tools are typically used while the application is running in order to provide more accurate results. This can make IAST more intrusive than SAST, as it can potentially interfere with the regular operation of the app.

On the other hand, DAST is different from both SAST and IAST as it focuses on analyzing the behavior of an application rather than its source code. DAST tools work by directly sending requests to the application and observing its response.

**Benefits of SAST**

There are many benefits of using SAST to improve the security health of your application, including:

*   **Improved overall security:** SAST can find vulnerabilities that other types of testing might miss. This means that your applications will be overall more secure.
*   **Reduced false positives:** since SAST analyzes the source code rather than the binaries or executables, it is less likely to produce false positives than its counterparts.
*   **Easier to use:** many SAST tools are easy to use and do not require a lot of training. This makes them ideal for organizations with somewhat limited resources.
*   **Faster results:** Unlike DAST and IAST, SAST tools can often find vulnerabilities much more quickly than other types of testing like manual code reviews.
*   **Lower costs:** SAST is usually less expensive than other types of testing, especially when comparing it to more intrusive methods like penetration testing.

**The Effect SAST Has On Security**

When it comes to testing the security of an application, SAST is an integral part of the security assessment, as it can find vulnerabilities testing methods might miss. Unlike other types of testing tools that can be used much later in the application’s software development lifecycle, SAST tools can test the security from the moment when the first lines of code are written.

This is why SAST has an incredibly positive effect on security – it can help the team of developers fix the problem even before it becomes one. For the vast majority of developers & applications, it is much easier to patch a vulnerability in its early stages and fix the line of code where it happens than to build a massive application only to remodel the code afterward.

**Conclusion**

We can conclude that SAST is incredibly beneficial & should be regarded as an essential part of the security assessment of an application. It can also help find vulnerabilities that other types of testing (like IAST and DAST) might miss, and it’s often faster and less expensive than its counterparts. So, if you are looking to improve the security of your applications, SAST is a great place to start.

Owais takes care of Hackread's social media from the very first day. At the same time He is pursuing for chartered accountancy and doing part time freelance writing.

How SAST Will Improve Your Overall Security: Intro

Developers need to think like WAF operators for security. Start with secure coding and think of Web application firewalls not as a prophylactic but as part of the secure coding test process.

A key approach to shifting security left is moving perimeter-focused security solutions down the stack by placing them in front of services and other infrastructure components, such as containers and container orchestration systems or API management systems and gateways.

While this does allow for more granular security, it's not a free lunch for developers. Just saying "The WAF will stop it" subverts the entire thinking and purpose of shifting left. Rather, developers must move from thinking of Web application firewalls (WAFs) as a prophylactic, to instead thinking of WAFs as a crucial part of their secure coding test process. Here's how they can accomplish that.

**The Explosion of WAFs and Cloud-Native Software**

While many companies still deploy WAF appliances, the fastest-growing segment of this market is WAF software that runs in the cloud. With the rise of cloud-native architectures and ephemeral infrastructure, more organizations are putting WAFs deeper into their application stacks — right in front of microservices. Some are even using WAFs for internal protection to enact robust zero-trust frameworks. So, the new reality is, developers are far more likely to come into close contact with WAFs today than at any point in the past. That said, WAFs at the microservice level are not foolproof.

**Before Deploying the WAF: Secure Coding Is Critical**

To start, developers must create applications under the assumption that all security controls can and will fail. This is important because it encourages them to build applications that are secure by default. Secure coding means using basic design principles — like code minification to obscure code — while ensuring that all variables and calls are checked against the OWASP Top 10 vulnerability list. There are dozens of ways that attackers can exploit poorly written code, including SQL injection, cross-site scripting, broken access controls, and file upload vulnerabilities.

A key part of this effort is to ensure developers are running linters and formatting checkers against all code. Usually, you will want developers to run code through software composition analysis (SCA) to identify risky dependencies and libraries that require updates. A secure coding process and mentality is more critical now because cloud-native microservices have turned security inside out.

At this point, the application security or DevSecOps teams run the code against some sort of simulation and add the WAF. For many developers, this is the end of the story. They assume, "We have deployed a WAF. We're safe now." They are wrong. Increasingly, the applications developers ship microservices, linked via APIs. Developers "own" their microservices and APIs and are responsible for security. The microservices and APIs may have highly specific rules and optimizations that can impact WAF behaviors and policies. Each application is different, and many unique APIs emerge.

For microservices, developers tend to rapidly ship code and make faster iterations on microservices because those smaller applications are loosely coupled and do not impact other applications. That makes for greater agility but also greater security risk if the changes are not run through the same cumbersome security process as observed at application launch.

**Learning to Think Like a WAF Operator**

Developers should always ask themselves before they ship code, "How will this impact my WAF coverage and security posture?" This question is good because it teaches them to think about how WAFs are working and not working — in other words, threat modeling.

Threat modeling is critical because there are known ways that attackers work around WAFs or exploit WAF weaknesses. For example, by default, Kubernetes exposes APIs for services and connections. Locking down Kubernetes APIs without messing up functionality is notoriously difficult, particularly if you're changing the applications and service calls in the applications on a regular basis. Recently, Shadowserver Foundation calculated that 84% of Kubernetes APIs servers had left themselves exposed to detection on the public Internet.

Understanding a WAF is a key precursor to threat modeling and, by extension, thinking like a firewall operator. Some WAF comprehension is tacit knowledge. For instance, tuning a WAF to limit false positives and false negatives to an acceptable level remains challenging. Developers looking to shift left can piggyback on experienced WAF operators to learn the tuning process and, in turn, better understand how the WAF responds to real-world traffic. Today, some organizations also deploy machine learning to help developers easily tune their WAFs by making rule and policy suggestions based on unsupervised learning across multiple WAFs.

**Better WAF Comprehension Leads to More Secure Code**

Even better, good WAF comprehension also transfers over into more secure coding. Developers that intimately understand WAFs — and have hands-on experience tuning them — benefit from tacit knowledge that is difficult to teach, and experience that goes beyond Open Web Application Security Project (OWASP} checklists. An equally good practice is, in a safe environment, to have developers work alongside red-team members to see how a smart attacker might compromise their apps and bypass default WAF settings.

The bottom line is simple: Developers, take time to know your WAF and learn its weaknesses. WAF wisdom will help you write secure code now and save your apps from being hacked in the future.

A WAF Is Not a Free Lunch: Teaching the Shift-Left Security Mindset

Zoo Management System version suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: Zoo Management System 1.0 - Stored Cross-Site-Scripting (XSS)# Date: 05/26/2022# Exploit Author: Angelo Pio Amirante# Vendor Homepage: https://www.sourcecodester.com/# Software Link: https://www.sourcecodester.com/php/15344/zoo-management-system-phpoop-free-source-code.html# Version: 1.0# Tested on: Server: XAMPP# Description:Zoo Management System 1.0 is vulnerable to a stored cross site scripting in “Add Classification” functionality of the admin panel.# Exploit:1)Goto: http://localhost/admin/public_html/admin_login and login with the provided credentials2)Goto: http://localhost/admin/public_html/save_classification3)The “Classification Display Name” and “Classification Table Name” are both vulnerable so you can put <script>alert(“xss”)</script> in one of them4)Goto: http://localhost/admin/public_html/view_classifications5) Stored XSS payload is fired# Image Poc:https://ibb.co/FXc5zLthttps://ibb.co/CtFSQrQ

Zoo Management System 1.0 Cross Site Scripting

Red Hat Security Advisory 2022-5153-01 - Red Hat Openshift GitOps is a declarative way to implement continuous deployment for cloud native applications. Issues addressed include a cross site scripting vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Important: Red Hat OpenShift GitOps security update  
Advisory ID:       RHSA-2022:5153-01  
Product:           Red Hat OpenShift GitOps  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:5153  
Issue date:        2022-06-22  
Updated on:        2022-06-24  
CVE Names:         CVE-2022-1271 CVE-2022-31016 CVE-2022-31034   
                   CVE-2022-31035 CVE-2022-31036   
=====================================================================

1. Summary:

An update is now available for Red Hat OpenShift GitOps 1.4.

Red Hat Product Security has rated this update as having a security impact  
of Important. A Common Vulnerability Scoring System (CVSS) base score,  
which gives a detailed severity rating, is available for each vulnerability  
from the CVE link(s) in the References section.

2. Description:

Red Hat Openshift GitOps is a declarative way to implement continuous  
deployment for cloud native applications.

Security Fix(es):

* argocd: vulnerable to a variety of attacks when an SSO login is initiated  
from the Argo CD CLI or the UI. (CVE-2022-31034)

* argocd: cross-site scripting (XSS) allow a malicious user to inject a  
javascript link in the UI (CVE-2022-31035)

* argocd: vulnerable to an uncontrolled memory consumption bug  
(CVE-2022-31016)

* argocd: vulnerable to a symlink following bug allowing a malicious user  
with repository write access (CVE-2022-31036)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

3. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

4. Bugs fixed (https://bugzilla.redhat.com/):

2096278 - CVE-2022-31035 argocd: cross-site scripting (XSS) allow a malicious user to inject a javascript link in the UI  
2096282 - CVE-2022-31034 argocd: vulnerable to a variety of attacks when an SSO login is initiated from the Argo CD CLI or the UI.  
2096283 - CVE-2022-31016 argocd: vulnerable to an uncontrolled memory consumption bug  
2096291 - CVE-2022-31036 argocd: vulnerable to a symlink following bug allowing a malicious user with repository write access

5. References:

https://access.redhat.com/security/cve/CVE-2022-1271  
https://access.redhat.com/security/cve/CVE-2022-31016  
https://access.redhat.com/security/cve/CVE-2022-31034  
https://access.redhat.com/security/cve/CVE-2022-31035  
https://access.redhat.com/security/cve/CVE-2022-31036  
https://access.redhat.com/security/updates/classification/#important

6. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYrn4XtzjgjWX9erEAQirDg//U2A5kMqqeRJL3OdGwKONtlLyN+bvVEnG  
RC93OzIhHnANwtztsosNuxkqMyglmcstB8OL3fKmyBMkSNQ00ZwcSFUscCQL68qs  
0Lfy+i+CLzHf2UM+lmVZtlmjCepZwUtWg9TgRp5CY1ctBvIdY9EcnJl337Ntd/qV  
pk5WaTTZYxCqe03QYuD6EkJ2+9Q8oe4ijXBXsIKZb1f4JtPoTXtFQgoSQpUv4Uux  
B8tMU6ddQ5zIY6l1V/gXF3wV9pD3y0ilvp2YmToF+G+E3N3bDT7whllcb/b6btni  
GE8DTh2Z4wyg4/2BPGG444n4fX7x0PjX6J8Ttcq7Uy1kP0DbFY6fS5SWTjbc/lKW  
aol6v3N1EmRKoGXetx9AymowUrGpaSeGvElN6gXQ0u4QrgivcDKzErlDnsz0hu/s  
hOqXb4lgrq/XSd/69SwQcUUmnbDWt8UN4MmkE94DVPfXkbIC+uRhv6VDFtYTarP5  
zu7zKHrGAsoYoi8aa1c1Lq3HxlSEc4l44KWJp/z1KWqxc0eebu8XHAoelJv35rX+  
gyX4/T2dsFLymwsxsseTf8LAm8u1CgUHsKA0XfSC7MrwnvXyTVJSkgj/MtTnSmv/  
N3HaqN9vj3Z5Py7EzmC4UGYnidaODfwmcODhwqEGXW4uxHNz4AyBU9KBZqf3w+8D  
TK1Fg89Smqg=  
=y2G6  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-5153-01

Admidio 4.1.2 version is affected by stored cross-site scripting (XSS).

Valid

Reported on

Jan 11th 2022

**Description**

Stored xss

**Proof of Concept**

    onmouseover="alert(1)">link</a>
    
    Video : https://drive.google.com/file/d/1WzArNdgXgjVOS6qsePRvGWIz6ljtxApx/view?usp=sharing
    

**Impact**

Through this vulnerability, an attacker is capable to execute malicious scripts.

CVE-2022-23896: Cross-site Scripting (XSS) - Stored in admidio

Cross-site Scripting (XSS) - Generic in GitHub repository ionicabizau/parse-url prior to 6.0.1

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2022-2217

**Cross site scripting in parse-url**

Moderate severity GitHub Reviewed Published Jun 28, 2022 • Updated Jul 5, 2022

We are still processing this advisory. You may have affected repositories that are not yet on this list. Check back soon for more.

**Package**

npm parse-url (npm)

**Affected versions**

< 6.0.1

**Description**

GHSA-q6wq-5p59-983w: Cross site scripting in parse-url

Cross-site Scripting (XSS) - Stored in GitHub repository ionicabizau/parse-url prior to 7.0.0.

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2022-2218

**Cross site scripting in parse-url**

Critical severity GitHub Reviewed Published Jun 28, 2022 • Updated Jul 5, 2022

We are still processing this advisory. You may have affected repositories that are not yet on this list. Check back soon for more.

**Package**

npm parse-url (npm)

**Affected versions**

< 6.0.1

**Description**

GHSA-jpp7-7chh-cf67: Cross site scripting in parse-url

A stored cross-site scripting (XSS) vulnerability in LightCMS v1.3.11 allows attackers to execute arbitrary web scripts or HTML via uploading a crafted PDF file.

A stored cross-site scripting (XSS) vulnerability exists in LightCMS that allows an user authorized to upload a malicious .pdf file which acts as a stored XSS payload. If this stored XSS payload is triggered by an administrator it will trigger a XSS attack.

    %PDF-1.4
    %1111
    1 0 obj
    <<
    /CreationDate (D:20210619104632+08'00')
    /Creator (xss)
    /Producer (PDF-XChange Core API SDK \(7.0.324.2\))
    >>
    endobj
    2 0 obj
    <<
    /Metadata 3 0 R
    /Pages 4 0 R
    /Type /Catalog
    >>
    endobj
    3 0 obj
    <<
    /Length 2983
    /Subtype /XML
    /Type /Metadata
    >>
    stream
    <?xpacket begin="﻿" id="W5M0MpCehiHzreSzNTczkc9d"?>
    <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0">
    	<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    		<rdf:Description rdf:about=""
    				xmlns:dc="http://purl.org/dc/elements/1.1/"
    				xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
    				xmlns:xmp="http://ns.adobe.com/xap/1.0/"
    				xmlns:pdf="http://ns.adobe.com/pdf/1.3/">
    			<dc:format>application/pdf</dc:format>
    			<xmpMM:DocumentID>uuid:9c93bc08-8e4e-46cb-b28f-824c693821a4</xmpMM:DocumentID>
    			<xmpMM:InstanceID>uuid:2cd63bea-24ca-4ef8-a12c-015da3b28c96</xmpMM:InstanceID>
    			<xmp:CreateDate>2021-06-19T10:46:32+08:00</xmp:CreateDate>
    			<xmp:CreatorTool>迅捷PDF编辑器 7.0.324.2</xmp:CreatorTool>
    			<xmp:ModifyDate>2021-06-19T10:52:02+08:00</xmp:ModifyDate>
    			<pdf:Producer>PDF-XChange Core API SDK (7.0.324.2)</pdf:Producer>
    		</rdf:Description>
    	</rdf:RDF>
    </x:xmpmeta>

CVE-2022-33009: A stored cross-site scripting (XSS) vulnerability exists in LightCMS "contents" field · Issue #30 · eddy8/LightCMS

A cross-site scripting (XSS) vulnerability in the System Settings/IOT Settings module of Delta Electronics DIAEnergie v1.08.00 allows attackers to execute arbitrary web scripts via a crafted payload injected into the Name text field.

**Delta-DIAEnergie-XSS****Delta Electronics DIAEnergie 1.08.00 Exists XSS Vulnerability****Vulnerability Introduction**

DIAEnergie in the "System Settings"--"IoT Hub Settings" menu bar, when creating a new "shift setting" (url is "/api/DiaSettings/PutIoTHubSetting"), perform xss test on the "name" field, directly When the page is tested, the system will prompt "A potentially dangerous Request.Form value detected from the client (name="123<script>alert(123)</script>")", but in fact the xss script has Submitted successfully.

download link：https://downloadcenter.delta-china.com.cn/downloadCenterCounter.aspx?DID=39971&DocPath=1&hl=zh-CN

**Vulnerability verification process**

1.  In the menu "System Settings" - "IoT Hub Settings", submit "<script>alert(123)</script>" in the name field when creating a new "Shift Settings"

2.success

CVE-2022-33005: GitHub - ZhuoNiBa/Delta-DIAEnergie-XSS: Delta Electronics DIAEnergie 1.08.00 Exists XSS Vulnerability

LDAP Account Manager (LAM) is a webfrontend for managing entries (e.g. users, groups, DHCP settings) stored in an LDAP directory. In versions prior to 8.0 the session files include the LDAP user name and password in clear text if the PHP OpenSSL extension is not installed or encryption is disabled by configuration. This issue has been fixed in version 8.0. Users unable to upgrade should install the PHP OpenSSL extension and make sure session encryption is enabled in LAM main configuration.

**Reflected XSS (Internet Explorer only)**

**Package**

ldap-account-manager (none)

**Description**

**Impact**

On Internet Explorer there is an XSS issue. This is mitigated by the fact that LAM no longer supports IE anyway. Also it has no more vendor support.

**Patches**

The issue is fixed in version 8.0.

**Workarounds**

Install a recent browser.

**For more information**

If you have any questions or comments about this advisory:

*   Open an issue in https://github.com/LDAPAccountManager/lam/issues
*   Email us on lam-public mailinglist

**Credits**

Arseniy Sharoglazov

Tag

#xss