When you maintain a lot of web applications on your server, sooner or later you may encounter a nasty surprise in the form of an unwanted add-on included in an application. These add-ons are of course backdoors, and in the case of web applications, the term “webshell” is used more often. Such a code fragment, uploaded to a server through a vulnerability in an application, allows for unauthorized access to files on the server. The attacker can also usually execute any commands on the compromised server. The probability of such a situation rises dramatically when you maintain an application based on one of popular CMSs – Joomla or WordPress. If you suspect that someone has obtained unauthorized access to your server, how can you solve the problem, locate the threat and remove it? This is explained it in an article entitled “Webshells”, published in the Sekurak ZIN #4 and later on the sekurak.pl portal.
The most popular CMS, thousands of plugins and templates, millions of users - this is WordPress. The question arises whether, along with the enormous number of functionalities that WordPress has to offer the user right after installation, it also provides adequate security? Although the current source of threats to WordPress lies in poor quality plugins and templates, it’s a good idea to take a few steps to improve the overall security level of one’s WordPress instance.
Reading the article “Hardening WordPress” published in the “Programista” 11/2016 magazine, the reader may learn, among other things, how to stop WordPress from disclosing redundant information or what threats might ensue from the option of user enumeration. In addition, the text provides a step-by-step explanation as to how to enable two-factor authentication using Google Authenticator, and how to proceed from Cross-site Scripting vulnerability to Remote Code Execution using the plugin and templates editor.
Update Jul 7, 2017: this article was published on sekurak.pl.
During the reading of RFC6749, one may have the impression that we are dealing with a document which is a description of the general instructions, the implementation of which allows to build the OAuth 2.0 support system. Such an observation is in accordance with the title of this document, in which the word “framework” appears. The OAuth 2.0 standard is therefore not a collection of strict and precisely defined rules. Leaving some freedom in the intrepreation of the RFC6749 instructions directly corresponds to a bigger amount of places in which the persons responsible for the implementation of the said standard may make mistakes. That is why the demand for an article arose - an article which will comprehensively explain what exactly this second version of the OAuth standard is and what its potential threats are. In order to satisfy the needs of the persons responsible for the implementation and testing of the OAuth 2.0 supporting solutions, I have decided to prepare an article which was published in the “Programista” 10/2016 journal.
Before proceeding to discussing the framework itself, the reader will go through a little revision on the knowledge of the meaning of the most important terms. We are speaking here, inter alia, about the presise explanation of the differences between “authentication” and “authorization”.
This article handles the following issues:
- The rules of OAuth 2.0 operation,
- What advantages we achieve applying this method of authorization,
- What OAuth is not, that is matters related to the application of OAuth for authentication,
- Methods which we can use for obtaining a token,
- Which method of obtaining a token we should choose for a given usage scenario,
- What security errors we can make using OAuth 2.0 - a list of vulnerabilities along with practical examples,
- OAuth in the mobile app environment (inter alia PKCE and the threats stemming from the usage of WebView).
The culmination of the text is in the form of a long list of questions which should be asked during threat modeling of applications using OAuth 2.0.
Update Feb 13, 2017: this article was published on sekurak.pl.
The development of WWW applications has made it increasingly necessary to implement solutions that allow asynchronous data exchange between the client and the web server. One of the proposed solutions was the use of the “long polling” technique; later on, AJAX came into the world of web browsers. The applied approaches seemed sufficient, but there was still place for improvement of the techniques used. This was particularly justifiable by the fact that there was a lack of methods for truly asynchronous communication where, once a connection was established, any party to the communication could decide at which point it would like to send a data packet. To meet this need, the WebSocket protocol was created.
As with most new technologies, there are specific security risks associated with WebSocket. In order to direct attention to them, I had prepared the text that was published in the “Programista” 9/2016 magazine. The reader may learn from him, among other things:
- How does WebSocket work?
- What is the security of data transferred using this protocol?
- What are the risks associated with using WebSocket (bypass authentication, bypass authorization, Same Origin Policy issues, injections, server resource exhaustion, and more).
- How to test applications using WebSocket with OWASP Zaproxy.
At the end of this article the reader will find a list of questions that should be asked during the security review of the application based on WebSocket.
Update Feb 2, 2017: This article was published on sekurak.pl.