Hackersidea

XML Injection testing is when a tester tries to inject an XML doc to the application. If the XML parser fails to contextually validate data, then the test will yield a positive result. This section describes practical examples of XML Injection. First, an XML style communication will be defined and its working principles explained. Then, the discovery method in which we try to insert XML metacharacters. Once the first step is accomplished, the tester will have some information about the XML structure, so it will be possible to try to inject XML data and tags (Tag Injection). How to Test Let's suppose there is a web application using an XML style communication in order to perform user registration. This is done by creating and adding a new <user> node in an xmlDb file. Let's suppose the xmlDB file is like the following: <?xml version="1.0" encoding="ISO-8859-1"?> <users> <user> <usern

An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser . This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts. The XML 1.0 standard defines the structure of an XML document. The standard defines a concept called an entity, which is a storage unit of some type. There are a few different types of entities, external general/parameter parsed entity often shortened to external entity , that can access local or remote content via a declared system identifier. The system identifier is assumed to be a URI that can be dereferenced (accessed) by the XML processor when processing the entity. The XML processor then replaces occurrences of the named extern

E arlier this year, after disclose potentially dangerous Meltdown and Spectre vulnerabilities that affected a large family of modern processors proven that speculative execution attacks can be exploited in a trivial way to access highly senssitive information Since then, several more variants of speculative execution attacks have been discovered, including Spectre-NG, SpectreRSB, Spectre 1.1, Spectre1.2, TLBleed, Lazy FP, NetSpectre and Foreshadow, patches for which were released by affected vendors time-to-time. Speculative execution is a core component of modern processors design that speculatively executes instructions based on assumptions that are considered likely to be true. If the assumptions come out to be valid, the execution continues, otherwise discarded Now, the same team of cybersecurity researchers who discovered original Meltdown and Spectre vulnerabilities have uncovered 7 new transient execution attacks affecting 3 major processor vendors—Intel, AMD

This article is focused on providing clear, simple, actionable guidance for preventing SQL Injection flaws in your applications. SQL Injection attacks are unfortunately very common, and this is due to two factors: the significant prevalence of SQL Injection vulnerabilities, and the attractiveness of the target (i.e., the database typically contains all the interesting/critical data for your application). It’s somewhat shameful that there are so many successful SQL Injection attacks occurring, because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code. SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input. To avoid SQL injection flaws is simple. Developers need to either: a) stop writing dynamic queries; and/or b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query. This article provides a set of simple techniques f