Are Frameworks Enough To Secure Applications or REST APIs?
The first question comes in our mind when we start with frameworks is “Are Frameworks enough to secure application?”
Answer is NO!
Developers prefer Frameworks to build fast and scalable Applications and REST APIs for clients as well as the audience. Many developers completely reliable on frameworks who understand the basic security fundamentals where others only focus to develop the Application. They leave behind some basic security flaws which may cause major impacts and compromises user’s privacy as well as organisation’s infrastructure. The security flaws completely depends on how much a developer is conscious about them while developing. To better understand the problems, we will have a look on some examples below using some critical security-vulnerabilities and will compare with developer’s coding structure to find out that the frameworks are not enough to secure your products.
I believe that you have the basic knowledge of OWASP top vulnerabilities and various frameworks.
Injections
Injecting vulnerability — where an end-user is capable of sending untrusted data to the server to execute SQL, NoSQL query, OS commands etc. to access private data available on the server. Injection has been placed on top of the OWASP list and carries a major impact, you may also loose the entire control of your own system/server.
Top Frameworks of different Languages are capable of sanitising the user- defined data. Framework uses ORM (Object/Relational Mapping) to map the data from the database to the end-user and vice-versa. ORM has custom methods to handle CRUD operations and also checks whether user-defined data is trusted or not. However, sometimes developer needs to perform the Raw Database Query to fetch data from Database or store data into Database which can be handled by ORM very well where it gives a method to perform Raw database Query. At this point, when the developer needs to write the Raw Query, the untrusted incoming inputs may harm user’s privacy and an attacker could be able to send miscellaneous data to the server and execute them.
Example: Laravel is the progressive PHP framework which have inbuilt ORM to perform Database Queries.
User wants to see it’s own Post — Developer writes an end-point for users to fetch user’s Post by `post_id`
URL
https://www.example.com/user/post?post_id=1Server-Side
$post_id = \Request::input(‘post_id’);
$user_post = Post::raw(“SELECT * from post_table WHERE id = {$post_id}”)What do you think? Above code is secure or not?
Of course not!
Developer directly passes user’s/attacker’s input data (`post_id`) into the raw query. At this point, developers should keep in mind that every time they code to execute some external command or query with user-specified data it must be sanitised and passes only trusted data to command or query.
2. Broken Access Control
Access Control is the core functionality of any application and API where it mostly depends on a developer to manage the Authorization using business logic. Let’s take an example to understand:
Example: Edit profile information.
A developer creates a Form to update profile information where the user edits the Username, Email, and Sex. The `POST` method used and the Action URL is;
https://www.example.com/user-info/update?user_id=1or as Framework’s Routing style
https://www.example.com/user-info/update/1Server-side handling
$user_id = \Request::input('user_id');
$user = User::find($user_id);
if($user){
$user->username = \Request::input('username');
$user->email = \Request::input('email');
$user->sex = \Request::input('sex');
$user->save();
} else {
return 'not user found';
}Find out the security flaw in the above mentioned code.
As we can see, we only catch the `user_id` and if the user is found in the Database we update the existing information with the provided information. What happens if the user/attacker changes the user_id form `1` to `any`?
Got that? cool…
Here is the logic which should be followed to update the Authenticated user information without breaking access control.
Many Frameworks provide the Global User Session Object in which only currently Authenticated user information is stored with the associated `user_id`. Let’s use it.
$user_id = \Request::input('user_id');
$user = User::find($user_id);//----Save the world----
$authenticated_user = \Auth::user();
if($authenticated_user->id != $user->id){
return 'unauthorised';
}if($user){
$user->username = \Request::input('username');
$user->email = \Request::input('email');
$user->sex = \Request::input('sex');
$user->save();
} else {
return 'not user found';
}
Here, just Three extra line appended by the developer saves the World!
Cross-Site Scripting (XSS)
Everyone knows about the XSS. We are going to take a scenario where only Frameworks are not responsible to protect us from the XSS attack. Almost all Frameworks come with the Template Engine which is responsible to handle Data Binding into Views and also responsible for sanitizing the Data to prevent XSS execution. Let’s take an example where a developer may leave the security flaws even after using the Template Engine.
Example: Most of the Template Engines use {{ }}, [[ ]], <% %>, etc. to bind the data into View Components. These syntax to escape any HTML entities in the content to prevent XSS. Template Engine also provides syntax when an application needs to bind the HTML which should be rendered into DOM. What happens if the rendered data is provided by an end-user/attacker? If the user sends XSS payloads which causes security flaw.
Here developer should use custom logic to escape the HTML and bind only trusted HTML into DOM.
Broken Authentication
Applications and APIs are related to Authentication in which management of Session, Cookie, Token or Password of Authenticated User should be secured and protected. Frameworks handle these things securely at first place and gives us an out-of-box session management feature where the developer gets the benefit of less code and do more. But sometime in excitement, developers forget to protect sensitive data such as Password, Token, Session, etc.
Example: Ruby on Rails is a Ruby Framework which provides method to create and destroy user’s session. When a user hit the logout method it redirects to the login page with a successful logout message. As of my personal experience in Penetration Testing, I found many Website which uses the Ruby on Rails Framework. I intercept the POST request of user profile update and store into Repeater (BurpSuit Tool) before hitting the log-out, now I hit the log-out option and the app redirects me to the login page with the successful log-out message but when I tried to hit the request which I earlier have captured into Repeater and send it to the server, unfortunately, the request still works. That means cookie does not expire even user log-out the session.
Here, we can say that Framework does not handle Authentication mechanism completely. It depends upon the developers who write the Authentication management and the session which should be deleted or get expired at the server-side after Log-out.
Conclusion
Framework is Secure, Fast, Scalable but often it depends upon the developer who writes the code. A developer must keep security in mind while implementing any functionality. The application running without errors is not enough when you are building small or enterprise level projects - consider security as your priority because the Frameworks are not enough to secure your product(s).
