Lately, have become interested in XSS and its prevention methods.
Most of the XSS prevention techniques focus on sanitizing the input for invalid characters and using them. This raises a question:
When it is obvious that the purpose is indeed an XSS attack why are we trying to strip the invalid characters and then going ahead with using the input instead of directly rejecting the input as such and sending the usage to an error page?
Am sure that everyone would have thought of this approach but somehow focus is on input validation,filtering and reusing instead of rejection. Why? What am I missing here?
The rule I use is, I use input validation to make sure data is valid according to the domain. If I expect a number and get a string of letters, I reject it. If however I have a text field that can include anything (like a comment on stack overflow), input validation and rejection is virtually impossible. So now I need to sanitize/output encode.
because mostly when input is wrong you already show an error page
for instance
page.php?id=a33
"select * from table where id = ".((Int)$_GET['id']);
the "num rows" value will be 0 because you are searching for:
"select * from table where id = 0";
in plus in some cases any string, even if corrupted can be useful for what the program is going to do, for instance a search string...
and again, don't do nothing can be frustrating for the user. better if sanitize and show a warning if some data were lost
Related
I have a sheet where I control provided services with columns filled with execution and conclusion dates.
These columns have data validation for invalid dates and also, for the user not to input weekend days or holidays (which is listed on another page of the same spreadsheet). So it has to be custom formula validation.
Validation formula:
=AND(ISDATE(K2)=TRUE;K2>=J2;WEEKDAY(K2)<>1;WEEKDAY(K2)<>7;COUNTIF(Holidays!$A:$A;"="&K2)=0)
also tried
=AND(ISDATE(K2)=TRUE;K2>=J2;WEEKDAY(K2)<>1;WEEKDAY(K2)<>7;ISNA(MATCH(K2;Holidays!$A:$A;0))=TRUE)
and also tried using INDIRECT("Holidays!$A:$A") on both options
***Column K has the data validation and Conclusion date is the input. Column J has execution dates. And row 1 has titles.
The problem:
data validation input rejection seems to work fine for the first couple of hours, sometimes a full day, but after this random period of time, it stops working. Actually it does work, but with the red flag, even though "Reject input" option is still checked.
My guess is that the problem resides on the reference being in another sheet, but I don't see any other way to do this, as including the holiday list to the main sheet would pollute it and hiding columns wouldn't be as practical since users update the list constantly.
Is there a way to make it work?
P.S. Conditional Formatting used to return error even when using INDIRECT for external reference but now Google seems to have fixed it.
Hope someone can help me.
custom formula for data validation:
=(ISDATE(A1))*
(WEEKDAY(A1, 2)<>6)*
(WEEKDAY(A1, 2)<>7)*
(NOT(REGEXMATCH(TO_TEXT(A1), TEXTJOIN("|", 1, INDIRECT("Sheet2!H:H")))))
custom formula for conditional formatting (valid green):
=(ISDATE(A1))*
(WEEKDAY(A1, 2)<>6)*
(WEEKDAY(A1, 2)<>7)*
(NOT(REGEXMATCH(TO_TEXT(A1), TEXTJOIN("|", 1, INDIRECT("Sheet2!H:H")))))
custom formula for conditional formatting (invalid red):
=((ISDATE(A1))*
(WEEKDAY(A1, 2)<>6)*
(WEEKDAY(A1, 2)<>7)*
(NOT(REGEXMATCH(TO_TEXT(A1), TEXTJOIN("|", 1, INDIRECT("Sheet2!H:H")))))=0)*
(A1<>"")
spreadsheet demo
I find the issue happens when the user is copying and pasting into the cell, instead of typing in, as part of a larger section of information. This breaks up the data validation into "pieces" because the copy and paste doesn't come with the data validation. I'm not sure if this is the case with you, but it may mean training users to copy and paste values only or only hard keying the information.
I have a transformation with several steps that run by batch script using Windows Task Scheduler.
Sometimes the first step or the n steps fail and it stops the entire transformation.
I want to transformation to run from start to end regardless of any errors, any way of doing this?
1)One way is to “error handling”, however it is not available for all the steps. You can right click on the step and check whether error handling option is available or not.
2) if you are getting errors because of incorrect datatype, for example: you are expecting a integer value and for some specific record you may get string value so it may fail , for handling such situation you can use data validation step.
Basically you can implement logic based on the transformation you have created. Above are some of the General methods.
This is what you called "Error Handling". Though your transformation runs with some Errors, you still want your transformation to continue to run.
Situations:
- Data type issues in the data stream.
Ex: say you have a column X of data type integer but by mistake you got string value. then you can define Error handling to capture all these records.
- while Processing json data.
Ex: the path you mentioned to retrieve a value of json field and for some data node the path can't identify or missing it. you can define error handling to capture all missing path details.
- while Update table
- If you are updating a table with some key, and if the key was not available as it is coming from input stream then an error will occur. you can define error handling here also.
I'm working on a program that will need to remove a JOB card from a JCL member. I'm having a lot of trouble building something that satisfies all possible options and configurations.
Below is a good guide on the JOB statement:
http://www.tutorialspoint.com/jcl/jcl_job_statement.htm
Some issues though:
There may be multiple job cards in a member
There may be comments in the job card
There may be characters in columns 73-80
There may be a SYSAFF, SET or similar statement directly following the JOB statement that should be retained but may begin with slashes and spaces just like a job card
Any help would be appreciated. Currently I have the following regular expression:
//.*JOB.*\n(//\s{4,}[^\s]+(\s|\d)*\n)+
Ultimately I only need to change the JOB name to fit the restriction of the FTP JES reader which requires your job name to be the submitting USERID plus exactly one character under JESINTERFACELEVEL 1 which is used by our site. Changing only the job name would also be acceptable.
With the information from your comment on Joe's answer, your task becomes easier.
//JJJJJAAA JOB other-stuff
If the second word is JOB and the first two characters of the first word are // and the third character is not *, then you have a JOB card. Remove the first word, replacing it with //JJJJJx, where x is your additional single character. JJJJJ represents the user-id.
This does assume that the user-id of the existing JOBs will be the same as the user-id of the new JOBs, in which case the replacement JOB name is not going to cause the extension of the JOB card.
If this is not the case, if the user-id on the original JOB cards is shorter, or indeed not a user-id at all and is shorter, either all or some, then I'd recommend splitting the JOB card after the first comma (if present).
In the unlikely event that you have very long accounting information and nothing else, this may cause a JCL error when the above is true. If so, fix the accounting information or get around the user-id limit. This is an unlikely situation :-)
If there is no accounting information but there is a long comment, this may cause a JCL error by accidentally hitting column 72 with data (so it will think the next line is a Continuation). In the unlikely even of that happening, fix it.
Neither of these two are worth coding for. They are worth verifying for, though the simplest way to do that is to watch and pick them up if they fall over.
You do have one more thing to watch for, and this is whether any of your steps use DD * or DD DATA. If they do, then you have to discover if any use DLM=. If they do, you will have to switch off the search for the JOB card when encountering DLM=, and switch it on again when you reach the delimiter value starting in column one.
Your single character may cause you problems. You will have a limited number of jobnames possible per userid. Unless allowed, JOBs with the same name will not run at the same time.
You will need to account for the two positional parameters -- 142 bytes of accounting information and 30ish bytes for programmers name. Also, you will have to account for the optional keyword parameters:
ADDRSPC= BYTES= CARDS= CLASS= COND=
GROUP= LINES= MEMLIMIT= MSGCLASS= MSGLEVEL=
NOTIFY= PAGES= PASSWORD= PERFORM= PRTY=
RD= REGION= RESTART= SECLABEL= SCHENV=
TIME= TYPRUN= USER=
Dealing with the JES commands like SYSAFF and other JCL commands like SET make it very complicated.
You might want to approach it in steps -- regex to handle the "//" followed by up to 69 bytes and continued with a comma except in cases of comments where it starts with "//*".
It might help to know what you are trying to accomplish. You can ask JES to process the JCL for you and there are ways you can inspect the parsed JCL via macros, exits and control blocks.
In most cases it's the first card anyway. Or at least the first non-comment card.
If a customer were "silly" (being polite here) enough to try and add, as an example, 4.6 items to their basket, what would you expect to see? or how would you deal with it. Obviously, we only deal with digital quantities (our hacksaw broke last week).
There seems to be a lot of inconsistence across the web.
Amazon Rounds down (4.6->4, 1.3->1)
FireBox Rounds (4.6->5, 1.3->1)
Ebuyer ignores the input (no error)
Expansys removes the item from your basket
I'm assuming some site will show an error
Which is the best solution
Add JavaScript verification that would remove non-numeric input while the user is typing in
Implement backward solution for the situation when JavaScript is off, either display an error message or round the value but then display a message saying "your input has been adjusted"
ADDED: Also be aware that the character that separates the fractional part from the integer one differs from country to country. In US I believe it is '.', in Europe it is usually ','. If your applications is targeted at customers in different countries with varying number representation, it would make sense to implement the support for both characters in your application logic. Otherwise some users will get format error messages without knowing why - non-techie people are often unaware of this format issue.
How about validating the user input and accepting only numeric characters?
One solution would be to bring the incorrect input to the user's attention so they can correct it. Rounding can be too much of an assumption depending on the context.
Displaying an error message next to the amount something like this: "I'm sorry, we cannot supply you with 4.6 items. Please enter a whole number." ...or something along those lines.
Another solution would be to avoid displaying error messages by restricting the input field to only allow valid input. ie If you don't want 4.6 items...only allow the user to be able to type 0-9. If the user can't enter incorrect input then there is never any reason to display an error message.
Assuming you're talking about a web app here, you can limit the characters allowed in the input box.
Alternatively, IMO you could use spinner (+/-) controls to change the quantity.
I believe tesco.com does this.
The best solution according to me would be
Customer enters: 4.6
Value changes to 5 after submitting (or if 4.4, round it to 4)
Notice is displayed telling the user that only integers are valid and that the system has roundedy "your" input (4.6) to 5
One solution would be to inform the user that their selection is invalid when they tab off the edit field that's allowed them to enter the fraction.
A lesser option would be to round (down, unless you're greedy to sell 1 extra item), or to reject the input completely.
The best solution is to prevent fractions in the first place by giving them a slider or spin control to select only whole numbers.
At the end it's always safer add server side check.
So if the input it's not an integer value:
I will redirect the user to the same form.
I will set the field with the floor value (4).
I will put on top of the field a message like"This field must be an integer value. May be did you want 4 pieces of this product?"
In my opinion if your product is an shopping system then it makes sense that primary goal is to sell some items. Usually customers want to perform as less actions as possible, so the system should predict what customer could possibly want when typing incorrect inputs.
Amazon Rounds down (4.6->4, 1.3->1) - the best for me, because everything after the decimal point can be destined to some other input;
FireBox Rounds (4.6->5, 1.3->1) - as for me I don't like when someone want to sell me more than I want to buy, so better 'floor' than 'round';
Ebuyer ignores the input (no error) - then you'll sell nothing and user needs to enter some values once again;
Expansys removes the item from your basket - terrible, now I need to search for the item in the shop once again;
I'm assuming some site will show an error. - not bad but required user to retype value;
I would implemented as Amazon plus informing user that input was not fully clear and asking him to recheck the value. So if the system guessed right then user need to change nothing but if he mistyped he'll see it immediately.
Also you could log all this kind of incidents and then perform an analysis, what user typed for the first time and what was the actual count he bought. Just for curiosity...
Well, you definitely should never round up. You should not ever bill for more materials than the customer requested, no matter how inane the request.
I am using CODBCRecordset (a class found on CodeProject) to find a single record in a table with 39 columns. If no record is found then the call to CRecordset::Open is fine. If a record matches the conditions then I get an Out of Memory exception when CRecordset::Open is called. I am selecting all the columns in the query (if I change the query to select only one of the columns with the same where clause then no exception).
I assume this is because of some limitation in CRecordset, but I can't find anything telling me of any limitations. The table only has 39 columns.
Has anyone run into this problem? And if so, do you have a work around / solution?
This is a MFC project using Visual Studio 6.0 if it makes any difference.
Here's the query (formatted here so wold show up without a scrollbar):
SELECT `id`, `member_id`, `member_id_last_four`, `card_number`, `first_name`,
`mi`, `last_name`, `participant_title_id`, `category_id`, `gender`,
`date_of_birth`, `address_line_1`, `address_line_2`, `city`, `state`,
`zip`, `phone`, `work_phone`, `mobile_phone`, `fax`, `email`,
`emergency_name`, `emergency_phone`, `job_title`, `mail_code`,
`comments`, `contract_unit`, `contract_length`, `start_date`,
`end_date`, `head_of_household`, `parent_id`, `added_by`, `im_active`,
`ct_active`, `organization`, `allow_members`, `organization_category_id`,
`modified_date`
FROM `participants`
WHERE `member_id` = '27F7D0982978B470C5CF94B1B833CC93F997EE23'
Copying and pasting into my query browser gives me only one result.
More info:
Commented out each column in the select statement except for id. Ran the query and no exception.
Then I systematically went through and uncommented each column, one at a time, and re-ran query in between each uncomment.
When I uncomment the comment column then I get the error.
This is defined as the following (Using MySQL): LONGTEXT
Can we assume you mean you're calling CODBCRecordset::Open(), yes? Or more precisely, something like:
CDatabase db;
db.Open (NULL,FALSE,FALSE,"ODBC;",TRUE);
CODBCRecordSet rs (&db);
rs.Open ("select blah, blah, blah from ...");
EDIT after response:
There are some known bugs with various ODBC drivers that appear to be caused by retrieving invalid field lengths. See these links:
http://forums.microsoft.com/msdn/showpost.aspx?postid=2700779&siteid=1
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=296391
This particular one seems to have been because CRecordset will allocate a buffer big enough to hold the field. As the column returns a length of zero, it's interpreted as the max 32-bit size (~2G) instead of the max 8-bit size (255 bytes). Needless to say, it can't allocate enough memory for the field.
Microsoft has acknowledged this as a problem, have a look at these for solutions:
http://support.microsoft.com/kb/q272951/
http://support.microsoft.com/kb/940895/
EDIT after question addenda:
So, given that your MySQL field is a LONGTEXT, it appears CRecordSet is trying to allocate the max possible size for it (2G). Do you really need 2 gig for a comments field? Typing at 80 wpm, 6cpw would take a typist a little over 7 years to fill that field, working 24 h/day with no rest :-).
It may be a useful exercise to have a look at all the columns in your database to see if they have appropriate data types. I'm not saying that you can't have a 2G column, just that you should be certain that it's necessary, especially in light of the fact that the current ODBC classes won't work with a field that big.
Read Pax's response. It gives a you a great understanding about why the problem happens.
Work Around:
This error will only happen if the field defined as (TEXT, LONGTEXT, etc) is NULL (and maybe empty). If there is data in the field then it will only allocate for the size the data in the field and not the max size (thereby causing the error).
So, if there is a case where you absolutely have to have these large fields. Here is a potential solution:
Give the field a default value in the database. (ie. '<blank>')
Then when displaying the value; you pass NULL/empty if you find default value.
Then when updating the value; you pass the default value if you find NULL/empty.
I second Pax's suggestion that this error is due to trying to allocate a buffer big enough to hold the biggest LONGTEXT possible. The client doesn't know how large the data is until it has fetched it.
LONGTEXT is indeed way larger than you would ever need in most applications. Consider using MEDIUMTEXT (max size 16MB) or just TEXT (max size 64KB) instead.
There are similar problems in PHP database interfaces. A PHP normally has a memory size limit and any fetch of a LONGBLOB or LONGTEXT is likely to exceed that limit.