Can someone tell me if there exists SQL code for Derby to change a username or password of a database? How may I reproduce this to prevent it in future in my application?
What I'm busy doing, is to create a custom SQL query builder in my Java desktop application, but I want to prevent an end-user to accidentally or purposefully delete any table or database, change the username or password.
What SQL scripts can be run here which I may cancel out in my coding, and what basic things am I missing here?
All thoughts appreciated.
(This question has been asked on SE/Security to get different views. I want to get as much info on this as possible)
Derby has an entire manual on security topics: http://db.apache.org/derby/docs/10.11/security/
Perhaps you can start by studying that manual, and experimenting with the approaches it suggests, and then ask some more specific questions?
Related
I am facing this problem in getting the new, update or deleted record from table in Oracle database to prefilled Google Form.
The Oracle database is with disabled permission to access the internet (ACL list) and according to recommendations that this is the best practice for Oracle databases.
I have managed to write some triggers in PL/SQL, but still no permission.
I have searched the internet, but I have not found anything that can help me with this scenario.
What I am thinking is to create a new Oracle database on the same server but with HTTPS permission access, using trigger on the old database to copy the record to the new database and a trigger on the new database to submit the record to Google form.
I have tried this idea, but each time I try to create new database I get errors.
So please, if you have other ideas in solving this issue, or helping with applying the scenario that I am thinking of.
My knowledge in Oracle databases is very shallow and their documentation from my point of view is that your topic is distributed under different chapters and sections which accumulate the felling of doubt that you are not in the right place the more you read in these sections.
I have an APEX application in which I need users(students) to be able to login and view their own information. I have both the usernames and passwords stored in a table within the database I'm using.
Is there a way of using these credentials to be able to log in individually? and how would I go about doing so?
I'm very new to APEX so sorry if this is an easy question.
Many thanks
Saying that each student has to see only their own data means - I presume (as it is about students) that there are as many database users (schemas) as students in your class.
If that's so, presuming that each of them will use their own Apex developer and its workspace (i.e. they won't share the workspace), I believe that you'll have to create that many Apex developers and assign each developer their own schema.
That should be done connected to the internal workspace, logged in as Apex admin.
However, as you have to create many users at once, that approach might be tedious. Instead, as you already have list of users stored in a table, you could utilize APEX_UTIL.CREATE_USER procedure and let it do the dirty job.
For example, if your table is MY_USERS, then such a script would do the job:
begin
for cur_u in (select username, password from my_users) loop
apex_util.create_user(p_user_name => cur_u.username,
p_web_password => cur_u.password
);
end loop;
end;
For more info, read this: https://docs.oracle.com/database/apex-18.2/AEAPI/CREATE_USER-Procedure.htm#AEAPI114
I would use a the Custom Authentication Scheme. It is documented, so if you need help, just clicked on the "?" buttons next to the various fields.
The example code is obviously not going to work, so please do not copy and paste blindly. Adapt it to your situation and hopefully, you are encrypting/hashing the passwords.
That gets you started with login (authentication). Next, to the second part of your question, that students should only see "their own information" (authorization). There are no clearcut answers to this question as there are many strategies available and many issues to consider. For example, how you design your application and data schema, what database features are available to you, and regulatory compliances that you need to meet.
A great starting point to read about these "database features" can be found here, on Real Application Security and Virtual Private Database.
The alternative includes a "poor man's implenentation of VPD" that Martin D'Souza wrote about a long time back.
HTH!
I'm currently making a website using PHP and MYSQLi. And I've been read a lot about SQL injection. As answered on other questions from StackExchange, 2 ways of prevent it is by using prepared statement and escaping string. Since I'm not able to do prepared statement (I've tried to make it based on tutorials and videos but can't make it work) so I chose another way(escaping string). My question is, if I change permission for user at my SQL login page, to only able to do 'SELECT' query. Will it able to give me extra security measure to prevent user from DROP, ALTER, etc on my database. Because my website :-
Not require any user to register.
The only text field link to my query is for full text search function (which only use SELECT for the query and I have mysqli escape string on this text field).
It's always a good idea to give your application's database login only the permissions it needs. If it doesn't need to do inserts or updates, don't give it insert or update permission.
However, attackers may still be able to exploit SQL injection vulnerabilities to read unauthorized data using select statements, so you still need to protect your queries against that.
Unfortunately, you get it all wrong (which is no wonder, given all the tons of rubbish posted in Stack Overflow).
prevent it by escaping string.
It doesn't prevent injections
Will it able to give me extra security measure
No.
I'm not able to do prepared statement
Consider hiring a programmer then. Think of your customers. And your business, after all. If you, say, want to be a bus driver, you have to buy a bus - not making it out of wood logs and clay, endangering your passengers. Exactly the same thing here - if you need a site to sell your goods - buy a site, instead of making it yourself
It is possible to create an trigger (with DBO) on a table which could not be disabled (even by DBO or the sa user)?
I need this trigger for licensing/permission purposes on a piece of software which is deployed on the SQL Server of clients. The problem occurs when the clients try to use an old version of my software and disable the triggers I created.
Not possible, if this happens there is deadlock condition, so all software don't want this.
Also it will make system prone to hackers, so you need to understand that this is not possible , sa user or Admin can everytime update rights.
You need to think some other approach like saving licensing in encrypted form, or some code around to fix up such kind of issues
How can I make my SQL statements not to appear in Profiler ?
They contain sensitive information and I don't want them to
show in Profiler.
Thanks for the replies !
The profiler can only be run by someone with proper rights so if your installation is properly secured you should be fine (no users should be able to profile your application).This goes beyond security, since profiler slows down the server considerably.
There is no way. The "text" column in profiler can not be removed from use.
You need rights to run profiler (sysadmin or GRANT ALTER TRACE) so it's not an implicit right.
Note:
sysadmins could decrypt stored procs or add logging code, regardless of whether they run profiler
physical access needs controlled, at least to stop someone taking a copy of the database away
things like sp_password or ALTER LOGIN are not traced anyway
Only way I can think of to do this would be to make them stored procedures (The profiler would only show the call), but if the arguments are what's secure (which is likely) then that won't help you (Edit: As pointed out in comments you can change the config of the profiler to include this anyway, so this won't help much)
Have you considered not giving access to people not allowed to view the data? Access to run the profiler is a pretty high level of access...
Also, have you considered hashing your data before storing/querying it? Sometimes that won't work, but if we're talking passwords then they really should be stored and looked up in an encrypted form anyway.
I've noticed if you use the encryption functions build into SQL (Written about at https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/sql-server-encryption?view=sql-server-ver15) like ENCRYPTBYPASSPHRASE, the text is not shown in profiler - I'm not sure if this is 100% fool proof but it does fit the question.
Example...