Microsoft Windows Forms® (WinForms) is a library that allows you to develop rich applications with graphical user interface (GUI). This library is a part of .NET Framework. Therefore, such a WinForms application can be developed with any .NET language (C#, F#, VB, etc.), and run on any platform supported by .NET Framework. Not only can it be run on Windows, but also on Linux or Mac OS X (see Mono project). Thus, WinForms is considered multi-platform. However, it is a rather old technology. For new projects, consider using Windows Presentation Foundation® (WPF) instead.
One of the key features of the QT framework is providing communication between objects via signals and slots. For QT developers, this is a very convenient and organic way to do things, but the nature of the feature does not allow to communicate between objects located in different address spaces. Therefore, the need arose to create a library that would allow to establish communication between objects located in different processes in a way when user just needs to connect signals and slots of these objects.
The results of this efforts I called the QRpc library, and here is how it is applied and built.
Microsoft SQL database optimization is a constant struggle for any project, and this is something that Apriorit tackles often as an R&D outsourcing company. The thing is, when developing an application, initially engineers tend to point all their attention towards actually writing the code, while performance takes the back seat. Often, performance problems are caused by the speed at which the data from the application is received. Some problems can creep past the MVP stage and only became apparent when your solution is fully released to the general public.
This guide will cover certain ways to detect restart or shutdown of the PC, as well as other similar events, such as log off or sleep. We will be handling the OS shutdown event using WinAPI for different types of applications - console, GUI applications, and services. If you’re interested in the general information on Windows process monitoring, you can also check out this article.
In this article you will find a short overview of I/O completion ports (IOCP), as well as a simple C++ implementation of copying folder with files by using I/O requests. We hope that this guide will prove useful for anyone with basic C++ and Windows API experience and will help them learn the basics and certain specifics of WinAPI IOCP programming.
Mac OS X 10.4 saw the introduction of a new kernel subsystem that proves itself very useful when it comes to managing authorization from the kernel. This subsystem is called Kernel Authorization, or Kauth. It can be used to modify any authorization decisions, which proves very useful for creating anti-viruses, and other security software, as well as for general system access when needed. In this article we will show you two examples of using Kauth subsystem – blocking access to certain files and directories, and listening for mounting and unmounting of specific devices. Both examples will involve creating kernel extension that will use Kauth in order to listen for specific events.
Since its introduction over 2 years ago, Swift gathered a lot of feedback, both positive and negative, and quickly established itself as a popular new iOS app programming language, as well as a great tool to write software for various Apple products. There are a lot of reviews on the Internet comparing Swift vs Objective-C and trying to determine the pros and cons of each language.
This tutorial provides you with easy to understand steps for a simple file system filter driver development. As a result, obtained demo driver is intended to print names of open files to debug output.
This article would be interesting for engineers with basic Windows device driver development experience as well as C/C++ knowledge. In addition, it could be also useful to people without Windows driver development deep understanding.
Web app vulnerabilities, as every developer knows, are a never-ending programming cat and mouse game with would be attackers. While there are too many security issues at times to count, keying in on those that continue to surface year in and year out we feel is an appropriate place to start.
Apriorit is an outsourcing company, focused on providing managed, dedicated R&D teams to both startups, as well as Fortune 500 industry leaders. Security has always been one of our core areas of expertise from the very beginning, yet at the same time, we count on extensive experience developing web applications for our clients. In this article we decided to share some of this experience and tackle the problem of how to avoid web app vulnerabilities. While there are scanner tools that can help you with the basic vulnerability assessment, the best way to ensure that an app is free of any vulnerabilities is to build it from the ground up with best security practices in mind. Since the topic itself is so broad, we decided to focus on three common examples that we will discuss in detail, communicate where the problem lies, and how you can avoid it. The Big 3 we will focus on in this article are: 1) Security Misconfiguration; 2) Broken session and authentication management; and 3) Cross-Site Request Forgery (CSRF).
A nasty threat, security misconfiguration can happen on a range of levels of an application stack. The platform, application servers, web server, database, framework and custom code can all be vulnerable. At a threat level, anonymous, external attackers can certainly be to blame but so can users that possess their own accounts who are steadfast in their desire to interfere in the system. Insiders especially who are seeking to disguise their actions are also in play.
From an exploitability standpoint, it is actually quite easy for an attacker to gain entry to things like unused pages, unpatched flaws, default accounts, as well as unprotected files and directories. Data recovery costs can be quite expensive when dealing with this specific application vulnerability, as the system can be fully compromised in some instances with data either stolen completely or altered at a snail’s pace over time.
So we ask you, is your application vulnerable? To begin, if your software is out of date (including but not limited to OS, DBMS, code libraries, Web/App Server and applications) then you could be subject to common web based application vulnerabilities. Next, consider engaging in these tested, prevention/solution steps to protect against security misconfiguration:
Similar to common vulnerabilities such as security misconfiguration, threat agents for broken session and authentication management can also be external hackers, users with their own accounts, as well as insiders. Statistics show that a typical attacker will prey upon authentication or session management flaws to in turn impersonate users. It is nasty work and the tools to achieve this can be through unprotected passwords, accounts or session IDs.
Custom authentication and session management schemes are commonly built by developers, but constructing them correctly is a whole other issue, as we all well know. Flaws to detect exploit lie in logout password management, remember me, account update, timeouts and similar such areas. The implementation is unique so finding the countermeasures to protect against these specific web application vulnerabilities is difficult to say the least.
The technical impact of these web application security vulnerabilities as they pertain to broken session and authentication management can be quite severe. For example, if the flaw gives way to some or potentially all accounts, in 2016 that hacker will have the tools to literally do what he/she desires. Privileged accounts are thus easy to exploit.
The larger question, how do you know if you’re vulnerable, and then of course, how to avoid web app vulnerabilities with respect to broken session and authentication management? Some key questions first to ask are:
It should be blatantly obvious that the principal assets a developer needs to protect to prevent these types of common web application vulnerabilities in 2016 are credentials and session IDs. One of the first things developers should do is make sure that SSL is put in place for all of the authenticated parts of the particular application. Moreover, credentials should be verified that they are being stored in a hashed form.
At the design stage developers can go a long way in also preventing these vulnerabilities. For example, not writing your own session handlers and instead using only the native session management mechanism. Nor should home-grown cookies be used for session-management or authentication. A single authentication mechanism should be used and once a user authenticates, a brand new session cookie should be issued coupled with the invalidation of the previous session cookie. This step in particular will put a stop to session hijacking attacks.
Some other design steps that can be taken are verifying every application page contains a logout link that can be easily identified. Also, shorter timeouts for inactive sessions are a must. Making sure the user actually knows their old password before activating a new one, not sending credentials, such as user name, over channels such as email, and not exposing session identifiers in the URL (session token for example).
When talking about web application security issues and solutions, CSRF frequently arises. From a solution standpoint there are clear countermeasures one can take and tools to prevent it. Basically, anyone who can input content into your users’ browsers and then oblige them to put forth a request to your website is a threat. For example, a website or HTML feed that users have access to could in theory do this.
So how does this work? An attacker would come up with false HTTP requests thus conning the victim into submitting these via XSS or image tags for example. If in fact the user is deemed valid, that attack of course succeeds. The principal security weakness here is the fact that browsers send credentials (session cookies and others) in an automatic fashion, potential attackers can in turn put together web pages which can run forged requests that are impossible to differentiate from legitimate ones. An attacker can thus trick a victim into making changes such as updating account details or even making purchases.
To avoid web app vulnerabilities associated with CSRF one method is to add a random value to the body of each form that is performing a sensitive transaction or processing sensitive data. This particular function will generate a long value (random) and connect it to the form as a concealed input field (named
Next, on the server you can place a code that will check for the presence of this same random value. To complete this you need to add a
ValidateAntiForgeryToken feature to the
ChangePassword action that in turn will process the form POST. This
ValidateAntiForgeryToken action is the final action required to prevent CSRF attacks. Once executed it will begin to perform a number of checks, such as:
_RequestVerificationTokenparameter and cookie are present.
Should any of the above fail, the request will stand as rejected. This works because with the addition of the random
_RequestVerificationToken factor to the
ChangePassword form, a potential attacker has a new, third value that they in turn will have to submit as an integrated part of their request.
While our Big 3 is just that, three real big threats, the good news is the solutions and countermeasures we laid out are implementation friendly and something our engineers have a lot of experience working with. Staying on top of similar threats is a matter of staying keyed in, and up to date. We hope that this article gave you a good idea on how to make your web applications more secure.