DEV Community: c org

Still Remember IndexedDB?

c org — Wed, 13 Jul 2022 16:38:18 +0000

We remember that there was a browser storage called IndexedDB like web storage and cookie.

IndexedDB is a large-scale, NoSQL storage system. It lets you store just about anything in the user’s browser. In addition to the usual search, get, and put actions, IndexedDB also supports transactions.

In this article, we’ll focus on the following.

-Why do we need IndexedDB?
-How do we use an IndexedDB in our applications?
-Features of IndexedDB
-Limitations of IndexedDB
-Is IndexedDB right for your applications?

Why do we need IndexedDB?

Indexed DB is considered more powerful than localStorage!

Do you know the reason behind it? Let’s find out.

Can store much bigger volumes of data than localStorage

There is no particular limit like in localStorage (between 2.5MB and 10MB). The maximum limit is based on the browser and the disk space. For example, Chrome and Chromium-based browsers allow up to 80% disk space. If you have 100GB, Indexed DB can use up to 80GB of space, and 60GB by a single origin. Firefox allows up to 2GB per origin while Safari allows up to 1GB per origin.

Can store any kind of value based on { key: value } pairs

Higher flexibility to store different data types. This means not only strings but also binary data (ArrayBuffer objects, Blob objects, etc.). It uses an object store to hold data internally.

Provides lookup interfaces

This is not available in other browser storage options such as localStorage and sessionStorage.

Useful for web applications that don’t require a persistent internet connection

IndexedDB can be very useful for applications that work both online and offline. For example, this can be used for client-side storage in Progressive Web Apps (PWAs).

Application state can be stored

By storing the application state for recurring users, the performance of your application can be increased drastically. Later on, the application can sync-up with the backend server and update the application via lazy loading.

Let’s have a look at the structure of the IndexedDB which can store multiple databases.

How do we use Indexed DB in our applications?

In the following section, we’ll look at how to bootstrap an application with IndexedDB.

1. Open the database connection using “window.indexedDB"

const openingRequest = indexedDB.open('UserDB', 1);

2. Create object store

Once the database connection is open, the onupgradeneeded event will be fired, which can be used to create object stores.

`// Create the UserDetails object store and indexesrequest.onupgradeneeded = (event) => {
let db = event.target.result;

 // Create the UserDetails object store 
 // with auto-increment id
 let store = db.createObjectStore('UserDetails', {
     autoIncrement: true
 });

 // Create an index on the NIC property
 let index = store.createIndex('nic', 'nic', {
     unique: true
 });

};`

Insert data into the object store###

Once a connection is opened to the database, the data can be managed inside the onsuccess event handler. Inserting data happens in 4 steps.

`function insertUser(db, user) {
// Create a new transaction
const txn = db.transaction('User', 'readwrite');

// Get the UserDetails object store
const store = txn.objectStore('UserDetails');    // Insert a new record
let query = store.put(user);

// Handle the success case
query.onsuccess = function (event) {
    console.log(event);
};

// Handle the error case
query.onerror = function (event) {
    console.log(event.target.errorCode);
}

// Close the database once the transaction completes
txn.oncomplete = function () {
    db.close();
};

Once the insertion function is created, the onsuccess event handler of the request can be used to insert more records.

request.onsuccess = (event) => { const db = event.target.result; insertUser(db, { email: 'john.doe@outlook.com', firstName: 'John', lastName: 'Doe', }); insertUser(db, { email: 'ann.doe@gmail.com', firstName: 'Ann', lastName: 'Doe' }); };

There are many operations that can be performed on the IndexedDB. Some of them are as follows.

-Read/search data from object stores by key
-Read/search data from object stores by index
-Update data of a record
-Delete a record
-Migrate from a previous version of a database, etc.

If you need insights about how to achieve the above, let me know in the comments section below. You can refer here for more information.

Features of Indexed DB

-Has an asynchronous API
-Supports transactions for reliability
-Supports versioning
-Private to domain

Is IndexedDB right for your application?

Based on the many features provided by IndexedDB, the answer to this million-dollar question could be Yes! However, before jumping to a conclusion, ask yourself the following questions.

-Does your application require offline access?
-Do you need to store a large amount of data on the client-side?
-Do you need to quickly locate/search data in a large set of data?
-Does your application access the client-side storage using the supported browsers by IndexedDB?
-Do you need to store various types of data including JavaScript objects?
-Does writing/reading from client-side storage need to be non-blocking?

If the answer to all of the above questions is Yes, IndexedDB is the best option for you. But if such functionality is not required, you might as well choose a storage method such as localStorage because it provides widespread browser adoption and features an easy-to-use API.

How to HACK Nginx

c org — Sat, 09 Jul 2022 22:20:08 +0000

Nginx is being used in the wild since a while now. We all have seen NGINX name somewhere while coding/hacking. NGINX has always been a target for hackers/bug bounty hunters due to a lot of misconfigurations in it, and as a security researcher/bug bounty hunter, hacking a web server always fascinates us. Today we will see how we can ACTUALLY hack a NGINX if it is vulnerable, and try to pick some bucks from it.

Well, if you are new to this topic, and somehow don’t know how NGINX as a server works, here is a description from internet:-

“Nginx is built to offer low memory usage and high concurrency. Rather than creating new processes for each web request, Nginx uses an asynchronous, event-driven approach where requests are handled in a single thread. With Nginx, one master process can control multiple worker processes. The master maintains the worker processes, while the workers do the actual processing. Because Nginx is asynchronous, each request can be executed by the worker concurrently without blocking other requests.”
You can obviously do a lot of stuff with the help of NGINX:-

Reverse proxy with caching
IPv6
Load balancing
FastCGI support with caching
WebSockets
Handling of static files, index files, and auto-indexing

So once we are clear how it works, our topics start..and the point is in which phase misconfigurations happen? Well, there are lot of things which can go other way if we don’t configure it properly. If you will go back in history, NGINX SPDY heap buffer overflow was exploited in 2014. To exploit this, the attacker can execute arbitrary code by specially crafting a request to cause a heap memory buffer overflow. This would gravely affect the web server. Also in 2020, PHP Remote Code Execution Vulnerability was found in NGINX which was severe and it was considered one of the most critical findings in this product ever. You can read more about them on internet. I leave it on you.

Since NGINX is the most common web server which is used these days, a lot of security issues are there too. We are talking about these today:-

Missing root location
Alias LFI Misconfiguration
Raw backend response reading
Unsafe variable use

1. Missing root location:-

Check the below code snippet:-

`server {
root /etc/nginx;

location /hack.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:1212/;
}
}
`
In NGINX, root directive specifies the root folder. In this example, root file is defined as /etc/nginx, it means that we can go ahead look upto nginx and files within it. So here if you will send a simple request like GET /nginx.conf it will reveal some sensitive info such as configuration of nginx and other stuff. Since “/” can handle any request, we can send a sensitive endpoint through it. In some cases it is possible to reach other configuration files and access logs.

2. Alias LFI Misconfiguration:-

It is always recommended to check “location” statements under NGINX configuration. If you find something like:-

location /imgs { alias /path/images/ }

You can go ahead and perform a LFI here. How? Expand it to /imgs../secret.txt and it will transform to /path/images/../secret.txt. You can read more about it here:- LFI/Path traversal.

3. Raw backend response reading:-

With Nginx’s proxy_pass, there’s the possibility to intercept errors and HTTP headers created by the backend. This is very useful if you want to hide internal error messages and headers so they are instead handled by Nginx. Nginx will automatically serve a custom error page if the backend answers with one.
Imagine there is an application like this:-

And it has following directives in NGINX:-

http { error_page 500 /html/error.html; proxy_intercept_errors on; proxy_hide_header Secret-Header; }

So if we send a simple GET request, our response will be something like this:-

HTTP/1.1 500 Internal Server Error Server: nginx/1.10.3 Content-Type: text/html Content-Length: 15 Connection: close

But what if we try to send an invalid request and check what happens next? Something like this:-

GET /? XTTP/1.1 Host: 127.0.0.1 Connection: close

If its vulnerable we should get a response with secret info:-

XTTP/1.1 500 Error Content-Type: text/html Secret-Header: secret

4. Unsafe variable use:-

A vulnerable NGINX configuration will look like this:-

location / { return 302 https://abcd.com$uri; }

The new line characters for HTTP requests are \r (Carriage Return) and \n (Line Feed). URL-encoding the new line characters results in the following representation of the characters %0d%0a. When these characters are included in a request like http://localhost/%0d%0aHacker:%20test to a server with the misconfiguration, the server will respond with a new header named HACKER since the $uri variable contains the URL-decoded new line characters

HTTP/1.1 302 Moved Temporarily Server: nginx/1.19.3 Content-Type: text/html Content-Length: 200 Connection: keep-alive Location: https://abcd.com/ Hacker: test

- proxy_pass and internal directives:-

The proxy_pass directive can be used to redirect internally requests to other servers internal or external. The internal directive is used to make it clear to Nginx that the location can only be accessed internally.

These were some common attack scenarios which arise in NGINX. There are obviously a lot of buffer overflows reported in this product, and it is always recommended to check everything which you can do on a particular server. Since NGINX is used as a load balancer as well, DOS is also possible there. However, the more they update the product, old vulns are getting vanished there. Since it is being used a lot, chances are new vulnerabilities will arise.

I hope you got something from this blog. Old folks know a lot of things, which are mentioned in this blog, are already available in this blog, so not a lot for those guys. But if you are new, you will surely get some good knowledge from it. I hope it helps you to learn a couple of things.

Now ready to hack.