I've an android app that has been reported by the Google Play Store to be at risk of sql injection, the app was written in native code (Java for Android).
The problem is: the sql commands (to be exact it is Sqlite) are not sent directly by the code, but are sent by a library integrated into the project (it would be really difficult to modify the library).
So to avoid sql injection I thought of inserting in the various text fields in the app some mechanism to recognize the sql code eventually entered by users and, in this case, blocks the flow of the app generating an exception.
Do you know if there is something that could be useful for this problem?
This is a bad situation to be in, you could look into OWASP SQLi Prevention Cheat Sheet for potential solutions but TBH exchanging the library might be the best way forward.
Related
I have an electron app which persists data in an SQLite db stored in my machine. I have all the setup for the CRUD operation and the application works fine. Now I need to encrypt the SQLite DB file. I searched online for solution but all the solution are for pre-encrypted DB which is being decrypted inside Electron.
The requirement is, user will provide the password using which the app will encrypt the DB file and going forward user will provide the password to decrypt and perform the CRUD operation
Any idea how to achieve this?
P.S.: I have checked with SQLCipher docs and I don't find what I needed. So far, I am using sqlite3 node module to perform CRUD
Edit 1: I tried to use sqlite-cipher module and I was able to encrypt the db in a separate js file. but when I integrate the same with the electron ipcMain, the app closes due to high RAM consumption.
Any suggestions???
If you're using SQLite the best option is use SQLCipher. The problem is that you will have to compile new binaries to work and there are some limitations with the versions of SQLite and SQLcipher for node.
You can use this package: https://github.com/journeyapps/node-sqlcipher
or compiling manually, here you have an example https://gist.github.com/aguynamedben/14253e34bc7e0a881d99c8e45eb45a47
Encryption in electron app is a tricky thing.
This is because it can give you false sense of security.
You might encrypt your local db, but with electron it's so easy to decrypt it back that perhaps it's not worth it at all?
It's very easy to get sources of your electron app. Minification helps only a little bit, but this is not real protection.
There are many approaches you can take but they vary on circumstances.
The questions which needs to be answered are:
who are you trying to protect against?
is security critical or this is only basic measures so not everyone can get data from db at first
glance?
does the user using the app have admin user rights on the
machine?
are you accessing db directly through electron app, or some
kind of system wide service (deamon) is communicating with db and
passing results to electron app.
if previous is "yes" how do you communicate the
service with the electron app and how is this secured?
Take a look at source code access discussion:
https://github.com/electron/electron/issues/3041
and also check this article (especially the security part):
https://hackernoon.com/electron-the-bad-parts-2b710c491547
I'm using Python and QT (PySide) in a local application (which connect to a database on cloud Azure).
Now, my objective is moving this app on the web, in particular on Azure (I have an Azure subscription), simply transfering it on Azure, it's possible in some manner? I have not found examples on the web.
The important question is: is Python QT (app web) compatible with Azure?
Thanks
UPDATED ANSWER!
Yes, now you can. Well sort of. The mad mads at Digia have created something called "QT for Web Assembly" that can compile your whole app into something that runs embedded into a web page.
https://doc.qt.io/qtcreator/creator-setup-webassembly.html
You might have to rethink connecting directly to the database however, as thats simply not gonna fly with web-sockets (And honestly direct app to remote RDBMS has never been a smart move. Theres a LOT of things that can go wrong letting the internet connnect to your databaes). But you could at least keep the UI and rewrite the databaes layer to interogate something like a GraphQL (or whatever) front end to the data.
OLD ANSWER
I'm afraid your up for a nearly complete rewrite. QT is a desktop/mobile platform. It doesn't go anywhere near HTML/CSS except perhaps for displaying them in a webview component. Azure or AWS won't magically make it into a web application for you.
Your code as it stands needd to be rewritten in a web-first transactional manner. That is it takes a request, processes it, produces a result. To some extent websockets has changed this dynamic for a limited subset of use cases where interaction needs to be non transactional, and modern web app design hides much of the transactionality behind a web-services model, but 90% of web work is still very much transactional.
Database <---> Web server/Web app stack <--- Internet! --> Web browser
My suggestion is to pick up Django (or one of the other systems. If its just simple, Flask is another good alternative. Flask for simple apps, Django for the big stuff. Or use something else, you have choices here!, and start from scratch. Analyse your products function and start mapping out how to make this work as a database driven transactional system.
Theres no shortcuts here, I'm afraid.
I'm working on a web app that will connect to a database to store and retrieve and manipulate data, and I was wondeiring if WCF is necessary. I've already deseigned and setup the database and i'm getting ready to start coding the app.
I read up about WCF but what i'm confused about is why i would need to use this layer when i can do the database coding inside the app itself by passing variable values directly into the database with stored procedures.. What am I missing?
BTW, I did research here and didn't see a question similar to this. I went to down two pages and typed "WCF necessary web app". No relevant hits...
WCF in this context is necessary if, for some reason, you need to have an abstraction layer between the database and the web app and you need to have this on another machine (or out-of-process). If that is not the case (likely) there is no need.
You might have noticed guidance to have an abstraction between the database and the web app. There are many pros and cons. Biggest con is effort. If you are not able to articulate clear benefits then you do not need to do this.
You do not "need" to do anything. Do what's right under your specific circumstances and requirements.
My friend asked me to make a registration software for his blood donation camp. He told me that he can't host an ASP.NET or PHP page.
Also that since they'll be running the software in many systems, which may not be interconnected, they may not be able to use a Database server.
Is there a way to store/read data from an MS-Excel or MS-Access file instead of any other database?
Also that I wish to make the front end using HTML & JavaScript/JQuery.
As you problem is little bit twicky. Since your app will run on various machine so you want to develop standalone app in Html / Jquery. Also you cannot use db server bcoz of lack of connectivity. So in such scenario i will suggest you to go for Win Form app with a lightweight db like MS Access and Sqlite. Which ever you prefer. Since you are keeping Network aside so i suggest you to not use HTML/Jquery to use access or Excel as it looks logical very easy to use interop with excel but implementation is quite messy. In that time you can finalize the winform app with any of the database with lots of ease.
We have a PeopleSoft installation and I am building a separate web application that needs to pull data from the PeopleSoft database. The web application will be on a different server than PeopleSoft, but the same internal network.
What are my options?
This one's an oldie but it may still be of interest.
PeopleSoft has it's own schema within the host database (Oracle, SQL Server, DB2 etc) which are the PSxxx tables, eg: PSRECDEFN is the equivalent of Oracle's DBA_TABLES. These tables should not be touched by any external code. The application tables are stored in PS_xxx tables, eg: PS_JOB. These tables can be read and updated by any SQL code.
Many batch programs in PeopleSoft (eg: Application Engines, COBOL or SQRs) access the tables directly, and this is the fastest way to get data into or out of the database. However PeopleSoft has quite a rich application layer which is bypassed when doing direct SQL. This application layer must be replicated in direct SQL code, especially for inserts or updates. There may be updates to other tables, calculations or increments of database-stored counters.
To determine how to do this one must look through the PeopleCode (a VB6-like interpreted language), page design (via Application Designer) and use the PeopleCode and SQL trace tools. These days the application layer is huge, so this can be a lengthy task for non-trivial pages. PeopleSoft groups related pages into "Components", and all pages in the component are saved at the same time.
Component Interfaces were introduced with PeopleTools 8 as a means to avoid doing all of this. Using a generator within the PeopleSoft app designer, a Component Interface is generated based on the component. For many components these can be used to access the pages as a user would, and can be accessed via PeopleCode programs, and therefore via App Engine programs and via the Integration Broker. They can also be wrapped in Java code and access directly by code able to execute against the app server with a web service wrapper. This method is best for low-volume transactions: heavy extracts work better with native SQL.
The online development and tracing tools in PeopleSoft are pretty good, and the documentation is excellent (although quite extensive) and available on: http://download.oracle.com/docs/cd/E17566_01/epm91pbr0/eng/psbooks/psft_homepage.htm
If you are just looking at bringing out data from a given Component, the easiest way would be to turn on the SQL trace (under the utilities menu in PeopleSoft) and bring up some records for the Component. Wading through the trace file will give you a good idea of what to do, and much of the SQL could be cut and pasted. Another method would be to find an existing report that is similiar to what you are trying to do and cut out the SQL.
Have a PeopleSoft business analyst on hand to help you develop the requirements wouldn't hurt either.
Yes - Integration Broker is Peoplesoft's proprietary implementation of a publish/subscribe mechanism, speaking xml. You could of course just write code that goes against your database using JDBC or OLE/ODBC. Nothing keeps you from doing this. However, you must understand the Peoplesoft database schema, so that you are pulling from, or inserting/updating/deleting all of the proper data. Peoplesoft takes care of this for you.
Also, check out Component Interfaces - and they are exposed as an API to Java or C/C++.
I guess it depends on your requirement, and which version of PeopleSoft you're on.
Do you want real-time lookup? If that's the case then you'll want to look at Web Services/Integration Broker.
If you want a batch/bulk export then a scheduled App Engine would do the trick.
The best way is to use Integration Broker (IB) services to expose the PeopleSoft database data to external applications. The external application will be able to access the PeopleSoft IB services as XML over HTTP, thus allowing you to use any widely used XML parsers for this purpose.
The problem with component interfaces as opposed to Integration Broker is that component interfaces tend to be much slower than direct DB access from within IB service PeopleCode. Also future additions to the component attached to the component interface sometimes tend to 'break' the interface.
For more details on PeopleSoft Integration broker, you can access the online documentation at http://docs.oracle.com/cd/E26239_01/pt851h3/eng/psbooks/tibr/book.htm
Going directly to the database means you have to re-create the presentation logic... see my longer answer above. You can do this for simple pages but otherwise using a component interface is the way to go.
You can also write a sqr process for bulk data extraction. SQR will create the output file which the other application can pick. SQR would be faster than the application engine programs as it performs most of the operations in memory.