I have found that all data of my 5 YEARS old site tables was suddenly mixed up
some data that cannot be updated via any existing sp is updated.
After long search of sp i came to conclusion that somebody messing with my site.
I assume that its done via sql injections.
I have huge amount of trafic on my site 24/7 ,site has more than 100 pages, and the logs are now just showing what user entered what page...more logs will slow down the site even more. so now i need to act efficiently.
1.What is the best way to find where someone injecting
2.how to log his ip and time of injection
never done this before, read lots of mixed opinions on google. please advice your best practise.
Instead of tracking down the "bad guys" you should focus on restoring your database and making your code resistant or invulnerable to injections, not sure whats the best way for asp.net but in java it is well known that prepared statements make it impossible to have somebody peform a sql injection on your data.
Check out this link for how to improve your code in asp.net:
Classic ASP SQL Injection Protection
This is some code I use on my page as a "catch all" attempt for injection attempts via query strings (ie, data sent through a URL):
trap = 0
ref = lcase(request.querystring)
if ref <> "" then
badChars = array("OR 1=1", "select", "drop", "shutdown", "--", "insert", "delete", "waitfor", "union", "0x31", "convert", "truncate", "sysobjects")
cn = 0
for i = 0 to uBound(badChars)
if instr(ref,badchars(i)) > 1 then cn=cn+1
next
if cn >=2 then trap = 1
end if
if trap = 1 then .... ban user ip code here
You could simply put "if trap = 1 then response.end" which would stop any further action on the page. I prefer to ban the IP for an hour.
This should also work with request.form for form input.
You may also want to sanitize your variables that take form input.
data=request.form("emailaddress")
data = replace(data,"'","")
data = replace(data,"union","")
etc.
Related
Is there a way to make the logged user (on superset) to make the queries on impala?
I tried to enable the "Impersonate the logged on user" option on Databases but with no success because all the queries run on impala with superset user.
I'm trying to achieve the same! This will not completely answer this question since it does not still work but I want to share my research in order to maybe help another soul that is trying to use this instrument outside very basic use cases.
I went deep in the code and I found out that impersonation is not implemented for Impala. So you cannot achieve this from the UI. I found out this PR https://github.com/apache/superset/pull/4699 that for whatever reason was never merged into the codebase and tried to copy&paste code in my Superset version (1.1.0) but it didn't work. Adding some logs I can see that the configuration with the impersonation is updated, but then the actual Impala query is with the user I used to start the process.
As you can imagine, I am a complete noob at this. However I found out that the impersonation thing happens when you create a cursor and there is a constructor parameter in which you can pass the impersonation configuration.
I managed to correctly (at least to my understanding) implement impersonation for the SQL lab part.
In the sql_lab.py class you have to add in the execute_sql_statements method the following lines
with closing(engine.raw_connection()) as conn:
# closing the connection closes the cursor as well
cursor = conn.cursor(**database.cursor_kwargs)
where cursor_kwargs is defined in db_engine_specs/impala.py as the following
#classmethod
def get_configuration_for_impersonation(cls, uri, impersonate_user, username):
logger.info(
'Passing Impala execution_options.cursor_configuration for impersonation')
return {'execution_options': {
'cursor_configuration': {'impala.doas.user': username}}}
#classmethod
def get_cursor_configuration_for_impersonation(cls, uri, impersonate_user,
username):
logger.debug('Passing Impala cursor configuration for impersonation')
return {'configuration': {'impala.doas.user': username}}
Finally, in models/core.py you have to add the following bit in the get_sqla_engine def
params = extra.get("engine_params", {}) # that was already there just for you to find out the line
self.cursor_kwargs = self.db_engine_spec.get_cursor_configuration_for_impersonation(
str(url), self.impersonate_user, effective_username) # this is the line I added
...
params.update(self.get_encrypted_extra()) # already there
#new stuff
configuration = {}
configuration.update(
self.db_engine_spec.get_configuration_for_impersonation(
str(url),
self.impersonate_user,
effective_username))
if configuration:
params.update(configuration)
As you can see I just shamelessy pasted the code from the PR. However this kind of works only for the SQL lab as I already said. For the dashboards there is an entirely different way of querying Impala that I did not still find out.
This means that queries for the dashboards are handled in a different way and there isn't something like this
with closing(engine.raw_connection()) as conn:
# closing the connection closes the cursor as well
cursor = conn.cursor(**database.cursor_kwargs)
My gut (and debugging) feeling is that you need to first understand the sqlalchemy part and extend a new ImpalaEngine class that uses a custom cursor with the impersonation conf. Or something like that, however it is not simple (if we want to call this simple) as the sql_lab part. So, the trick is to find out where the query is executed and create a cursor with the impersonation configuration. Easy, isnt'it ?
I hope that this could shed some light to you and the others that have this issue. Let me know if you did find out another way to solve this issue, or if this comment was useful.
Update: something really useful
A colleague of mine succesfully implemented impersonation with impala without touching any superset related, but instead working directly with the impyla lib. A PR was open with the code to change. You can apply the patch directly in the impyla src used by superset. You have to edit both dbapi.py and hiveserver2.py.
As a reminder: we are still testing this and we do not know if it works with different accounts using the same superset instance.
We got a problem with Microsoft Access .mdb-files. After some time working with an .mdb-file in a multiuser environment the file becomes corrupted and has to be repaired. After it's repaired it takes less time to become corrupted again. And at some point after multiple reperations the file isn't usable at all anymore.
This problem started to appear after we changed from MS Access Runtime 2010 to MS Access Runtime 2013.
I've already spent some time looking into this problem and this is my theory:
The mdb-file appearently contains a "Database Header Page" (described in a White Paper from Microsoft called "Understanding Microsoft Jet Locking" from 1996) which saves information about the commit bytes of Users (important: 0000 = writing to disk, 0100 = accessed a corrupted page). And there is a paragraph in the white paper about this Database Header Page which explains exactly what is happening in our problem:
"[...]Therefore, if a value of 00 00 is present without corresponding user lock [this would be an entry in the corresponding .ldb-file I think], or a value of 0100 is present, users will not be allowed to connect to the database without first executing the repair utility."
So my guess is, that after some amount of loosing connection to the mdb/breaking the connection this Database Header Page overflows and you have to repair the file but the repair doesn't remove every entry inside of this Database Header Page, so the amount of broken connections needed for the file to become corrupted decreases until the file completely breaks.
Now I would like to know if this theory is any good and if it is I would like to know:
How can I test this theory (how can I read this Database Header Page of the mdb-file)?
Can I modify the Database Header Page?
Can I modify the Database Header Page while someone is working with the mdb?
I know it's a very specific problem but I hope you guys can help me!
P.S. I can't find a link to the white paper but the "LDBViewer"-packet contains this white paper.
A few quick and dirty tricks that I often use are enabled by creating a small database which serves one purpose: control how the desired target database is opened.
This database is copied to the desktop of every user, so every user/session has its own.
So I would have
* 1 database on a server-location : [TheBigOne.mdb]
* 1 database copied to several desktops : [TheCaller.mdb]
--01-- :
Every morning, call a function which will perform the following steps :
* rename [TheCaller.mdb] to [TheCaller-xxx.mdb]
* create and open [TheCaller-NEW.mdb]
* for all tables, queries, forms, reports, macros, modules
DoCmd.TransferDatabase acImport, , [TheCaller-xxx.mdb], _
acTable-acQuery-acForm-acReport-acMacro-acModule, "y", "y", False
* rename [TheCaller-NEW.mdb] to [TheCaller.mdb]
--02--
Create a form in [TheCaller.mdb] with one button, with an OnClick-event like :
If Dir(ServerLocation & "\TheBigOnd.ldb") = "" Then
'open [TheBigOne.mdb]
Then
Msgbox "Database already in use!"
End If
This is prone to a lot of headaches, because it will happen that the [TheBigOnd.ldb] file does exists, while no one is using the database. But at least, you will have less database-corruption.
--03--
An alternative for this procedure --02-- can be achieved by using a command-line switch /excl. At any given time, only one user will be able to work in the database.
--04--
Create a second button on the form from point --02--, which will open [TheBigOne.mdb] with command-line switch /ro. This will open the database in a read-only mode for this user, avoiding the corruption of the database.
--05--
Create a small backend database db_sessions.mdb on a server-location, with
a table in it like T_Sessions(id, whois, started_at_timestamp, ended_at_timestamp, excl_or_ro, troubles) for keeping track [who] [opens] and [closes] [when] the database [TheBigOne.mdb].
If a user wants more priviliges then read-only, the following test has to be true: DCount("*","T_Sessions","ended_at_timestamp is null AND excl_or_ro = 'excl'") = 0. If this test results in false, the field troubles can be used to dispatch messages to other users.
I'm working in a legacy app for the moment, upgrading Access 2003 to link to SQL Server tables (2008 R2 or later). With tables linked by code, I can insert, but not update or delete. I've tried everything on the web, no dice. Details below.
Being terse so not tl;dr.
Tables first created using upsizing wizard. In use, app has to connect to different ones in same schema, so can't just set and forget. Can't do local DSN's, many installs, though DSN file is possible. But problems there too, DSN not found. Details later.
Before the rest: Soon I'm further updating this app to Access 2016 or so. If this is different enough / easier there, I'll wait a few days. Maybe someone could suggest the best refsite for that.
* problem details follow *
Using a DSN and the UI to link a table, I get an editable table. Hurray.
But when I use the code below (found on every refsite), link is made but only selecting and inserting work. Everything else fails fails fails, no matter what.
Public Function LinkToSqlTable(sqlInstance As String, sqlDb As String,
sqlTableName As String, localTableName As String)
Dim linked As New TableDef
' ***factored-out functionality, known to work: reader can ignore*** '
DeleteTable localTableName
' connection-string steps, placeholders replaced by args '
Dim sCnx As String
sCnx = "ODBC;Driver=SQL Server;Server=_instance_;" & _
"Database=_db_;Integrated Security=SSPI"
sCnx = Replace(sCnx, "_instance_", sqlInstance)
sCnx = Replace(sCnx, "_db_", sqlDb)
' linked-table steps '
Set linked = CurrentDb.CreateTableDef(localTableName)
linked.Connect = sCnx
linked.SourceTableName = sqlTableName
CurrentDb.TableDefs.Append linked
' ui '
RefreshDatabaseWindow
End Function
* ID column or permissions? *
I thought the problem was lack of identity column originally, I added one, but no change. At least now I have a PK field like I should. ;-)
When I manually link table, UI demands to know the ID column. So could it still be it? Fine, but how do I set that in code? Searches revealed nothing.
I assume then it's permissions as sites etc. say. I also took all the steps I could think of to fix that. No dice.
* things I've tried *
Aside from the ID-column stuff I said before, these things (not in order):
Since DSN saved as a file, tried using it as exampled, in cnx string. Fail.
Used DSN contents, carefully winnowed & translated, in cnx string. Fail.
Used connection string from the table that I had connected manually with DSN. Fail.
Changed driver in cnx string across all major options, even omitted it. Fail.
Changed security in cnx to Integrated Security=SSPI and other options, and omitted entirely. Fail.
I added my actual local user as exampled, with and without password. Fail.
(Previous few options tried across earlier options, though not 100% coverage.)
In SQL Server, using SSMS, I tried security power:
Added SQS-authentication login to the instance
Matching user to the default db seen here
Gave that login-user read and write permissions in db here (plus others, sometimes)
Added matching id & pw to the cnx string. Fail.
I tried setting up this db in SQS to have let-everyone-do-everything "security" temporarily. Fail.
This, that, and the other thing. Everything fail!!
So a permissions issue? Some way to use DSN file after all? Mismatched permission settings in my cnx string? Boneheaded oversight? Something else that I've missed? I'm pretty good at both SQL Server and Access, but only at a basic level in their security stuff and connection strings are the devil.
* retrieved table properties *
Just in case they help, I retrieved these (after objects added to TableDefs collection).
** This one, done in UI and with DSN and this-is-ID-field, worked with editing: **
Name = dbo_tblSendTo
Updatable = False
DateCreated = 4/19/2016 11:11:40 AM
LastUpdated = 4/19/2016 11:11:42 AM
Connect = ODBC;Description=SQL Server tables for TeleSales 5;DRIVER=SQL Server Native Client 10.0;SERVER=(local)\sqlexpress;Trusted_Connection=Yes;APP=Microsoft Office 2003;WSID=CMSERVER;DATABASE=TS5_General;
Attributes = 536870912
SourceTableName = dbo.tblSendTo
RecordCount = -1
ValidationRule =
ValidationText =
ConflictTable =
ReplicaFilter =
** And this one, from table linked via code, didn't: **
Name = tblSendTo
Updatable = False
DateCreated = 4/19/2016 11:17:51 AM
LastUpdated = 4/19/2016 11:17:51 AM
Connect = ODBC;Description=SQL Server tables for TeleSales 5;DRIVER=SQL Server Native Client
> 10.0;SERVER=(local)\sqlexpress;Trusted_Connection=Yes;APP=Microsoft Office 2003;WSID=CMSERVER;DATABASE=TS5_General;
Attributes = 536870912
SourceTableName = dbo.tblSendTo
RecordCount = -1
ValidationRule =
ValidationText =
ConflictTable =
ReplicaFilter =
* my plea *
So..... Please someone help me out. I don't like feeling stupid like this, and regrettably I need to do this instead of replacing it with .NET code or similar.
Thanks, anyone who can...
Ed.
Alas, I am able to answer my own question.
edited a little since first posted in reply to HansUp's comments
I had added an identity column to the table that I couldn't edit. However, I had not set it up as a primary key. It turns out that using identity doesn't make something a primary key automatically.
But the latter, making it primary key using either of the 2 possible DDL syntaxes, is crucial. Since I thought I had dealt with the no edits without unique key problem, I focused on permissions.
All of the permissions things here, then, are just a sideshow.
The upshot of this is to be sure to add an identity column and make it a primary key if for some reason your original table schema didn't have that.
If I have the time, I will be trimming the question to reflect what I've discovered.
I have been consolidating 3 Databases into one via prefixes in my mediawiki installation. I got three wikis using the same database like so:
en_interwiki
de_interwiki
es_interwiki
Everything works fine out of visitor perspective... but whenever a USER wants to post a new article or commit edits, the database takes up to 35 seconds to respond. This is unacceptable.
I activated debugging like so:
# Debugging:
$wgDBerrorLog = '/var/log/mediawiki/WikiDBerror.log';
$wgShowSQLErrors = true;
$wgDebugDumpSql = true;
$wgDebugLogFile = '/var/log/mediawiki/WikiDebug.log';
$wgShowDBErrorBacktrace = true;
I am getting debug info, and it seems that pagelinks is the culprit, but i am not one hundred percent sure.
Did anyone ever have this issue before?
Please help me!
Best regards,
Max
I could fix it. In my case, the memcache had the wrong port. Everything is back to normal.
In case anyone uses memcache with their MediaWiki installation: Be sure to use the right port on your server, or you will end up like me, with 30 second-wait-times.
In our web application, we observed the following:
GetUser/CreatMembershipEntities/ExplicitLoadFromAssembly seems quite expensive.
Also noticing that CreateEntityConnection is being called - EntityFramework?
I'm not entirely convinced that EF was configured correctly for this application. If it was, and was in use, I wouldn't expect to see new connections to be initiated for every call - yes/no?
Is a way to streamline this to avoid some major code refactoring?
The use of System.Web.Security.Membership.GetUser() seems like a biggie here. Instead of using the MembershipProvider to create users, what about just executing a sproc that does the same things.
I have found the following code that is ridiculous, as far as I am concerned - in causing a new call for each user until a unique one can be generated:
For i As Integer = 1 To Integer.MaxValue
'Generate unique username
If System.Web.Security.Membership.GetUser(userName & i) Is Nothing Then
'Increment value until no duplicate username found
userName = userName & i
Exit For
End If
Next
-- UPDATE--
I have modified the question slightly...
We were able to run up to 20 users then the IIS server would tank. Does the GetUser() method create a brand new connection every time? It looks like it, based on the results. How can I ensure that this GetUser() thing is actually using the db context, rather than spinning up its own connections?