JSONP injection is a lesser known but quite widespread and dangerous vulnerability and it surfaced in the last years due to the high rate of adoption of JSON, web APIs and the urging need for cross-domain communications.
What is JSONP?
Assuming everybody knows what JSON is, let’s talk a little about JSONP. JSONP comes from JSON with Padding and it was created in order to bypass common restrictions such as Same-origin Policy which is enforced for XMLHttpRequest (AJAX requests).
Let’s take an example. Our online banking application, http://verysecurebank.ro, has implemented an API call that returns the current user’s transactions.
An HTTP request to the http://verysecurebank.ro/getAccountTransactions endpoint presents us with the transactions, JSON formatted:
If our reports application, accessible at http://reports.verysecurebank.ro wants to get the transaction details, an AJAX call to the page won’t be possible, due to Same-origin Policy being in effect (different host).
Note: even if it might be obvious, it’s worth mentioning that when including a script cross-domain, it will run in the context of the including application, not in the source’s context.
Adding a callback to the API response, wrapped around the JSON formatted data, allows us to load the API response between script tags and get its content by defining our own callback function to handle it.
There are various cases when during an IT/ security assurance projects there are specific requirements to rely on penetration testing projects/ reports completed by a third party.
However, not always, the IT security auditors have the necessary information to assess the quality of the penetration testing projects (focusing on planning, projects delivery and reporting).
And I address here the IT security assurance projects having in scope IT systems and finalizing with an Independent Auditor Report (IT Audit Opinion) and not audits focused on processes (like ISO audits) or on specific IT controls relevant for specific objectives (like ISAE 3402 IT/ Security assurance projects).
IT/ Security auditing standards
In order to have a consistent and objective assessment of third party reports, an IT security auditor must refer to the auditing standards he is using for performing his engagement.
And if we consider the IT audit standards available on the market, we must look at ISACA framework. There are also other standards applicable to various industries or specific objectives, focused on management systems, like ISO standards, but ISACA’s are the only ones of general nature which can be used cross-platforms, industries, etc. And as support for this, I performed some quick Internet searches and found mostly the same views.
For example, in one of its papers, NIST recognizes the entities enumerated below as addressing the IT auditing within their standards, further states that all of them taken essentially the same position concerning audits involving information systems and continues focusing on ISACA’s CobIT.
- The American Institute of Certified Public Accountants (AICPA) in several Statements on Auditing Standards (SASs);
- Institute of Internal Auditors Association (IIA) in its Standards for the Professional Practice of Internal Auditing;
- Information Systems Audit and Control Association (ISACA) in its “ITAF™: A Professional Practices Framework for IS Audit/Assurance”
- S. General Accounting Office (GAO) in its Government Auditing Standards and Title 2, Accounting.
Probably you’re here because you’re interested in obtaining the OSCP certification. Smart decision, good for you! Or maybe you are interested in obtaining a certification in info-sec, but you are still looking for the right one? Even if you are just looking for a way to boost your technical skills, you may be interested in becoming an Offensive Security Certified Professional.
I recently went through the course (Penetration testing with Kali Linux) and certification exam, so here is some of my experience and a few thoughts, you might find them useful.
There is no secret that in order to obtain this certification, you need to dedicate a great amount of time and ambition and I completely agree with this.
Also, rumour has it that you already need to have Godlike skills in everything there is to know, or else you won’t understand the materials. I can honestly say that the rumours aren’t true. A strong background in info-sec is preferred, however the course materials are very well explained, there are plenty resources for learning your way through this course, all you need is the determination to try harder and read more, until you fill all knowledge gaps that might appear.
If you missed the first two parts of this article, you can find in Part I what is a shellcode, how it works and which are its limitations and in Part II you can read about the PEB (Process Environment Block) structure, the PE (.exe, .dll) file format and you can go through a short ASM introduction. You’ll need this information in order to properly understand Windows shellcodes.
In this last part of the shellcode development introduction, we will write a simple “SwapMouseButton” shellcode, a shellcode that will swap left and right mouse buttons. We will start from an existing shellcode: “Allwin URLDownloadToFile + WinExec + ExitProcess Shellcode“. The shellcode name tells us a few things, such like it uses:
- URLDownloadToFile Windows API function to download a file
- WinExec to execute the file (executable file: .exe)
- ExitProcess will terminate the process running the shellcode
If you missed the first part of this series, where you can read about what is a shellcode and how it works, you can find it here: Part I. In this part, I will cover required information in order to be able to properly write a shellcode for Windows platform: the Process Environment Block, the format of Portable Executable files and a short introduction to x86 Assembly. This article will not cover all the aspects of these concepts, but it should be enough in order to properly understand shellcodes.
Process Environment Block
Within Windows operating system, PEB is a structure available for every process at a fixed address in memory. This structure contains useful information about the process such as: the address where the executable is loaded into memory, the list of modules (DLL), a flag specifying if the process is being debugged and many others.
It is important to understand that the structure is intended to be used by the operating system. It is not consistent across different Windows system versions, so it may change with each new Windows release, but some common information has been kept.