I am just trying to see if this is the reason for a recent bug:
Values in a certain table are sometimes NOT inserted properly, this seems to have arisen after a change I made to the text-encoding on this website, from ISO-8859-1 to UTF-8 because of text display errors on the website itself. At the time, I did not know this could cause DB errors, but the DB is encoded in Latin1 which I believe is the same as ISO-8859-1.
Could the page with forms, being UTF-8, trying to inserts into a Latin1 db, cause a HARD insertion error for certain queries -- that is, the query fails entirely, as opposed to entering in strange character strings due to encoding mismatch?
EDIT -- I am asking because I cannot myself replicate the insertion bug, I can only observe that it has happened twice to other users. These users do not seem to use special characters in their registration, which adds to the confusion...
Thank you sincerely for your help and time,
-H
Related
I wrote a small c# service importing tarcking numbers to a single UDF separated by a , (comma). The problem is that occasionally (maybe every 200th document) a comma is saved as a semi-colon. A kind of similar issue I have is with the Amazon importer where I add a comment. Maybe with the same frequency, the comment has a whitespace between every single original characters. All in common is that the error cannot be within my code. There is no difference between the correct documents (ca. 95%) and the others.
Does anybody have an idea how i can workaround that these issues don't appear anymore?
Or why this can happen?
I know I have an outdated SAP B1 at version 9.2 PL 10 Hotfix3. DI-API is linked to the install folder. Is this issue fixed in any later version?
(Current workaround is a cron job checking for wrong entries in the db and update those documents. Very uncool)
Definitely sounds like a DI-API bug. If you posted your code it would help confirm this.
Assuming it IS a DI-API bug, I would "dark side" it and just do a regular SQL update (bypass the DI-API), since it's just a UDF and there's probably not any business logic you need SAP to perform on these updates.
Alternatively, you could normalize your data and create a separate table linked via FK to your current table to house a single UDF per row (therefore not having to deal with the weird coma character issue).
As a third alternative, you could make of the SBO Post-Transaction Notification SP to monitor for your error case and perform the "fix" there, intead of in your cron-job.
Disclaimer: I have not worked with SAP in 4+ years.
I have API like
"/getXXXX?ABC=X7TRYUV&Ab_DEF=true&Ab_XYZ=true&Ab_ExZ=ZXTY"
How can I check the vulnerability of the request parameters?
What type of strings I can pass?
I ran the API in Wapiti and SQLMAP tool but found no issue.
manually i have tested it with by manipulating "Ab_ExZ=ZXTY" to 'CHR(91%2d1)'XTY
and It filter out the result as correct parameter where it should not filter out.
Thanks,
Bibek
Unfortunately the answer to your question is it depends. There is a lot of useful information about injection style attacks available from OWASP. The exact strings that you should use depend on the underlying technology of your solution and the characters e.g. terminating characters that are significant at each stage the data is processed.
A starting point for testing injection is to try to terminate the statement / command. For example in Oracle PL/SQL the characters '; will work by the quote closing the string entry and the semi colon terminating the command. If the query is prone to injection attacks this will most likely give you an error from the database for a malformed query.
Obviously other databases will have slightly different syntax. Also worth considering is the underlying OS. If the input to the API is ending up being executed at the command line, is it Windows or Linux based? This will change the syntax that you want to try.
Finally, if data is being stored where is it then rendered? If it becomes rendered in a Web UI you can try inputing <b> obviously if your API allows this to be stored and then displayed to the user without being escaped you will see text in bold. This would indicate a second order injection attack. (The actual risk is when the data is retrieved rather than being sent).
I strongly recommend taking a look at the injection information available on OWASP's site. Including the WebGoat examples where you can have a go at trying injection style testing against a deliberately vulnerable web site. The principles will translate nicely to the API testing.
Using FCKEditor
We are trying to place the clubs character into the database and bring it back out. The first couple times, the character is saved correctly, but after a couple of edits to the file the html encoding of the clubs character is being lost when saved to the database.
Any ideas?
version 2.3.1
Short answer... updated to newest version and the problem was corrected.
I need to log the last time the user signed in using my node.js server. I am looking into three options. The persistence requirement is not super high, meaning that the margin of error of this record being recorded is open.
Use SQL DB and whenever the user logs in it modifies their profile account.
Record it in a server text file. So whenever the user logs on, this file will be opened and updated. The opening, recording and closing of the file will all be done asynchronously.
I'm thinking that the second option is the better on because I'm using SQL for many other operations so I prefer to not interrupting my DB as much as possible.
One concern I have for the second option is the performance hit on the server that will be caused by the frequently read and write to a local text file.
I'm curious what other people who have gone through this path thought about my thought process. Any opinions or tips are highly welcomed. Thank you.
Normally you should use a SQL database, it is a much more better way than the plain text.
The main problem with a text file is that when you log in, you can simply append a line (but what about a couple of user loggin in at the same moment ? You have not any warranty that all the access are logged), but when you want to extact the last login for a user, you should read (and then load) all the file from the start (or the end), which can cause a really worst problem than the access to the DB.
Naturally you can work out all the problems with a text file, but then you have written a lot of code to avoid a simple update query.
I don't think that, with the information you give, you should be worried about the performance of a database access in this case.
MS SQL 2008: I tried searching for this but didn't really find an answer. I know that all user input should be sanitized and validated before being saved to the database, but I'm wondering if that is also necessary for fields that are limited in the database by size and type.
For example, I have several fields that are of BIT type and would only allow 1 character, or INT fields that have a foreign key designation, so only foreign keys can be saved into it.
So now, on a form where I have a user send a message to another user, I could have
Radio button BIT (contact me yes/no)
hidden field (send to #userid#) so this will place the ID of the user into the table
DateTime field (message sent on this date) Will be automatically populated by me, but I'm throwing it in here, let's say I let the user set the time.
VarChar (max size 2), this one I wonder about, I'm guessing even just being limited to 2, a person could inject something malicious into it?
Do I need to sanitize these fields before sending them to the database, or will the database handle and reject the input?
The reason I'm asking all of this, is to find out what is generally accepted and also for performance reasons.
Thanks.
You need to sanitize your inputs to prevent malicious users from modifying your SQL query through the data to do something bad. I don't think changing the type or size will contribute to the security of your system. Your DBMS will reject any inserts where the data is of the wrong size or type.
Datatypes are not the answer to security. Datatypes should be appropriate for your business requirements. For example, if you have a requirement to allow people to rich text paragraphs, such as I am doing right now, (see rich text), then a char(10) field with html stripped out might be secure, but useless.
You've already been briefed a bit on sql injection. You also have to take heed of malicious html and javascript. Just for fun, insert this:
<script>alert("oh dear");</script>
into your database. Then write a simple .net/php/coldfusion/whatever app that selects it and displays it on a web page. Dollars to donuts it executes.
Your question has already been answered. This is just more stuff to consider.