I have a client site that is getting a load of users registered that are very obviously bogus. The site uses xmod forms on 4 pages but those forms look to be immune to SQL injection. I have thought maybe this was a cross site scripting attack but not sure what vector may have been used.
Can anyone tell me or point me to documentation of specific attack vectors for DNN 6 so I can stop the madness.
Thanks
Upgrade to DNN7?
Are you sure they aren't just using an automated script to register accounts?
Security bulletins http://www.dnnsoftware.com/Platform/Manage/Security-Center
From what i read,
DNN team says they're immune to SQL Injections but you do have to or upgrade or enter the code yourself so it depends on the site and what year is it from.
Official response to this subject from the DNN team:
"Recently we've received a number of emails to the security#dotnetnuke.com alias from users who's sites have suffered from sql injection enquiring whether DotNetNuke has any sql injection issues. The short answer is no. For sql injection attacks to work typically the code needs to execute dynamic sql i.e sql statements that are built up via concatentation and executed directly against the database or else within a stored procedure that executes the statement via EXEC or sp_execute. As a matter of policy we avoid using both those approaches and instead only use stored procedures with parameters, so default installations of DotNetNuke and any core modules are not vulnerable to sql injection attacks."
Related
I am using Vugen 1 version. I want to connect it to Oracle 11g. Someone could please mention the complete process for it as I did performance of web applications earlier. Thanks.
The core question is whether it is an ORACLE problem or whether you have an installation issue with LoadRunner. Fortunately, LoadRunner ships with sample applications which can be used as control elements to determine whether this is LoadRunner or ORACLE based.
Look to your sample applications. Look for the FlightDB application. This is an ODBC based application and will tell us if your LoadRunner application is installed correctly. Record this application via ODBC. If you cannot record the flights DB application successfully then this would point most likely to a failed installation or a failure to meet the credentials level required by the application. Anti virus software can also be antagonistic to the ability to record, so disabling this may provide a benefit.
Only once the FlightDB application is working successfully should we turn back to the ORACLE application. From there, start at a primitive level, with the SQL+ for Windows application. This application is about as basic as one can get. Record an ORACLE virtual user, using SQL+ for WIndows as the application. Record a Sign on in the Init(), a query in the Action() and a logout in the End() sections of your test code.
IF that does not work, but the FlightsDB application does work, then it is time to look at your Oracle environment for issues. After using the control applications of FlightDB and the SQL+ for WIndows applications and having success, then turn back to your ORACLE application. If you are still unable to record then you may have an application which is not architecturally as pure ORACLE as you may think. Could it be a JDBC application, running in a Java environment? Could it be an OLEDB connection? Is it a .Net application? All of these could potentially turn you towards a different route to build test code.
The question is really too vague as already pointed out.
Anyway Oracle - 2 Tier Protocol is what you're looking for.
File -> New Script and Solution -> Oracle - 2 Tier. Record with sqlplus.exe (C:\Program Files\ORACLI_X32\12.1.0\BIN or ORACLI_X64\12.1.0 depends on your installation).
Follow the instruction on the prompt screen (DB, Username, PW, Query, exit) and stop recording.
I am completely ignorant in relation to databases and servers etc. Please bear with me.
I am trying to install a program called RealProspect 2009 which allows both local and remote sql database installation. Both types are done using the program installation .exe.
I have an azure account on which I have set up a server, and a database. During the program installation I am asked to provide the SQL server address, SQL server name, SQL username and SQL password. Using the information provided in the Azure online tools, I input all of this information into the fields and the program commences installing the database on the remote location. If I use incorrect information in these fields the installation returns an error and tells me it cannot log in, or the IP is not allowed etc., so I know it's actually attempting to connect and verifying the connection credentials.
When I use the correct server and login information the program proceeds. It spends several minutes "Creating the Tables". When it finishes doing that it attempts to begin "Installing Default Data (Categories)". At this point the program stops and I get the error in the subject line of this post "Invalid Object name 'Categories' "
I don't know enough to tell you what I don't know about this process.
I just signed up for Azure specifically because hosting the database with Azure is like $5-10 per month and I want myself and several other participants to be able to use the software with a common database. I created the server and database using the gui "tools/how to" from within the online Azure portal and I have never written a script, or accessed the server/database using anything other than the online GUI.
Thank you in advance for any help you may be able to provide. I hope i'm not too much of a speed bump to your day.
P.S. - For what it's worth you can download a free trial of the software from realinvestorsoftware.com and see if you could install it on a remote server. Maybe you can better see what I see and tell me how to do it on my own?
SQL Azure is VERY similar to SQL Server but there are a few features that SQL Azure doesn't support. That said, I'd be surprised if the app's installer is using any of the features that are unsupported by SQL Azure. My guess is that there's a bug in their installation scripts that might fail on more modern versions of SQL Server (note, their app installs on SQL Express 2005 which is no longer in mainstream support).
Just a couple of other thoughts for you: You get keys to install the app on two machines but:
"If you would like to install on more than two computers, then after you order your copy of RealProspect you can login to your customer account on this website and order additional activation keys for only $97 each."
Because you're going to be paying several hundred dollars anyway, and because (you yourself admit) you're not a database expert, it may be less cost, stress and hard-work to use their $27 per month database hosting service. That way you can concentrate on building your business while they take care of the technology.
[Update: 3/27/2013 # 23:05]
Another option Chris presented was to install the app and database locally and then migrate the database to Azure.
While this is potentially feasible, it requires some finesse to execute.
Microsoft provides a DB migration guide presenting several (pretty manual) options.
You might also want to read this thread which discusses how to migrate your DB via a DACPack.
Another option is to download and use the SQL Azure Migration Wizard which should do most of the heavy-lifting for you and make your DB migration simpler.
However, note that it is possible that the DB the app uses may use features of SQL Server that are not supported on SQL Azure. Hopefully this isn't the case, but be aware that this may be an issue.
Good luck :)
Chris,
I think SQL Database Migration Wizard v3.9.10 & v4.0.13 will solve your problem, I have used this tool several time to migrate db from local machine to sql azure, the most beauty of this tool it also highlights the error or sql which couldn't be migrated to Azure, so we can easily find alternate syntax of such sql queries
I'm just starting to spec out a project that will be a fairly advanced DB with a fairly simple MVC front end, accessible over the internet, I'm unsure of how to handle users, I can see two options:
Option 1 - Use SQL Servers in-built Logins/Users to handle user authentication and use the in-built user access to control who can access what (almost everything will be selects or stored procs).
Option 2 - Use my own list of users (with hashed salted passwords) and my own access control list (possibly using proc name and OBJECT_NAME(##PROCID) passed to another proc) and do all writes/reads of the DB through an application profile with access to all procedures/views.
I've searched but can't find any reasons I should pick one over the other, can anyone share a link or provide reasons why one is better that the other (or if there are glaring issues with both)?
If you need any more details please let me know.
If using SQL authentication (Option 1 for each user) via a connection pool, you're going to get comparatively poor performance. You'll get pooling for each user, but that could still mean 100's or 1000's of connections. There are ways around that, but the solution begins to start making Option 1 work like Option 2, so you might as well use Option 2.
I've seen a few solutions that create SQL Accounts to do the inital authentication for each user (via a single application based SQL account), then the rest works like Option 2 (again via a single application based SQL account). Those cases were using lots of SQL accounts, so each user could own a set of Views, and imitate Schemas. As Schemas & Aliases have been available since SQL Server 2005, it wouldn't be worthwhile to pick option 2 anymore for that reason.
Finally, don't use SQL Server Application roles either - they're bad security practice. Brian Kelly covers a few of the issues (pos & cons) in an article about them (http://www.sqlservercentral.com/articles/Security/sqlserversecurityprosandconsofapplicationroles/1116/).
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is it possible to password protect an SQL server database even from administrators of the server?
I am hosting my database on SQL Server 2008 on a windows 7 machine. The Windows 7 machine and the SQL Server 2008 are controlled and administered by third party admins.
I have sensitive information in my database.
How do I secure my database, so that the third party admins do not look at the sensitive data?
Is there any way to restrict the third party admins from copying the stored procedures, table designs etc.
Only to a limited degree.
If they are administering the actual SQL Server Instance as well they have the "keys to the kingdom". They can view the definitions of every object, make changes to the definitions or the data, and do virtually anything else. Even if they merely have admin rights on the machine but not the server, they can get admin on the server through certain techniques which are generally considered valid rather than bugs or exploits. It is after all their server and the server will obey them.
In a situation like this, you need to be able to trust those admins at least to a degree. If you cannot trust them, you should ideally not be hosting with them at all, and if you can't trust them and must host with them, try to get your own VM where you can at least apply some additional security and auditing.
There are a few things you can do though, but none are completely effective.
The first is encryption. If you meet all the requirements and set it up properly, SQL's transparant data encryption can prevent an admin without the keys from reading the data (but they can still see the structure!) in the database. This is quit effective at protecting the actual data (but not the structure) but is difficult to set up properly.
You can use the "with encryption" option to protect your stored procedures. This is very weak protection and its very easy to get around this. But it at least sends a strong message to the curious that you don't want them looking and makes them jump through some hoops.
Traces and auditing will also help you determine what happened and see if they did anything, but those come at a performance price.
Hi there is no perfect defense for this issue you have to follow some steps to protect up to some extent like
If you don't want any people in the admin group on the server to be able to access the database, then remove the "BUILTIN\Administrators" user on the server.
Enable auditing
Enable Encryption
Use third party tools at io level that block crud to the database unless a password is provided
I got VPS with limited memory and my WCF service is hosted using AppFabric.
Since memory is limited and I am not using SQL server for anything other than AppFabric prerequisite im thinking about uninstalling SQL Server. (instance can eat up to 200mb memory at times). I am not using any DB related features of AppFabric like dashboard or caching. I like IIS extensions and simplicity for WCF service manipulations however, and I am thinking those do not require Sql Server actually.
I am unable to just try it out so wonder if someone has such experience, or can predict result of uninstalling SQL server on appfabric behaviour.
Instead of uninstalling SQL Server you could just stop the SQL Server process. Set the process to manual startup.
That way if you need SQL Server in the future you can just start the process.
As #Shiraz Bhajiji illudes to if you are using SQLServer as the configuration store, you will need to reconfigure it to use file based configuration instead, it sounds like you are only using a single AppFabric instance, but if you are or needed to use multiple instances the config file would need to be accessible to all instances.
Again it isn't necessarily relevant to you, but if you have multiple app fabric instances, the sql server configuration option is a much more robust approach. With the file based approach, if you configure things incorrectly one app fabric node going down can take down the entire cluster. The SQLServer approach does represent a single point of failure however, if you are using clustering etc you can easily mitigate this. Again I appreciate I'm getting a little off topic here.