I wanted to make a really easy JavaScript validation for the IBAN.
It is for a project on school what means the goal of the validation isn't to get a 100% good IBAN validation but something easy to get along with.
I tried to create my own:/^[A-Z]{2}+[0-9A-Z]*$/
But apparently it seems to disactivate all the Javascript in the same file.
What is the reason that this disactivates all my JavaScript, and what is a good validation?
The conditions of the validation (might it not be clear already):
The first two characters must be alphabetic and upper-case.
The other characters can be numeric and/or alphabetic.
The length doesn't have to be included because that is checked with another if-statement in my function.
That's because you're using two-quantifiers side-by-side
/^[A-Z]{2}+[0-9A-Z]*$/
// ^ Remove this. It means match the previous token one or more times
So, it would be /^[A-Z]{2}[0-9A-Z]*$/
Related
I have an input field where I expect the user to enter the name of a place (city/town/village/whatever). I have this function which is use to sanitize the content of the input field.
sanitizeInput: function (input) {
return input.replaceAll(/[&/\\#,+()$~%.^'":*?<>{}]/g, "");
}
I want to remove all special characters that I expect not to appear in place name. I thought a blacklist regex is better than a whitelist regex because there are still many characters that might appear in a place name.
My questions are:
Is this regex safe?
Could it be improved?
Do you see a way to attack the program using this regex?
EDIT: This is a tiny frontend-only project. There is no backend.
Your regex is perfect to remove any special characters.
The answers are :
1.the regex is safe , but as you mentioned it is a vuejs project so the js function will run on browser. Browsers basically not safe for doing user input sanitization. You should do that in backend server also , to be 100% safe
You can not improve the regex itself in this example. But instead of regex , you could use indexOf for each special characters also ( it will be fastest process but more verbose and too much code)
Like :
str.indexOf('&') !== -1
str.indexOf('#') !== -1
Etc
3.same as answer 1,the regex is safe but as it is used in browser js , the code an be disabled , so please do server side validation also.
If you have any issue with this answer ,please let me know by comment or reply.
It is important to remember that front end sanitization is mainly to improve the user experience and protect against accidental data input errors. There are ways to get past front end controls. For this reason, it is important to rely on sanitizing data on the backend for security purposes. This may not be the answer to your question, but based on what you are using for a backend, you may need to sanitize certain things or it may have built in controls and you may not need to worry about further sanitization.
ps.
Please forgive my lack of references. But it is worth researching on your own.
I regularly receive emails from the same person, each containing one or more unique identifying codes. I need to get those codes.
The email body contains a host of inconsistent email content, but it is the strings I am interested in. They look like...
loYm9vYzE6Z-aaj5lL_Og539wFer0KfD
FuZTFvYzE68y8-t4UgBT9npHLTGmVAor
JpZDRwYzE6dgyo1legz9sqpVy_F21nx8
ZzZ3RwYzE63P3UwX2ANPI-c4PMo7bFmj
What the strings seem to have in common is, they are all 32 characters in length and all composed of a mixture of both uppercase, lowercase, numbers and symbols. But a given email may contain none, one or multiple, and the strings will be in an unpredictable position, not on adjacent lines as above.
I wish to make a Zap workflow in Zapier, the linking tool for web services, to find these strings and use them in another app - ie. whenever a string is found, create a new Trello card.
I have already started the workflow with Zapier's "Gmail" integration as a "trigger", specifically a search using the "from:" field corresponding to the regular sender. That's the easy part.
But the actual parsing of the email body is foxing me. Zapier has a rudimentary email parser, but it is not suitable for this task. What is suitable is using Zapier's own "Code" integration to execute freeform code - namely, a regular expression to identify those strings.
I have never done this before and am struggling to formulate working code. Zapier Code can take either Python (documentation) or Javascript (documentation). It supports data variables "input_data" (Python) or "inputData" (Javascript) and "output" (both).
See, below, how I insert the Gmail body in to "body" for parsing...
I need to use the Code box to construct a regular expression to find each unique identifier string and output it as input to the next integration in the workflow, ie. Trello.
For info, in the above screengrab, the existing "hello world" code in the box is Zapier's own test code. The fields "id" and "hello" are made available to the next workflow app in the chain.
But I need to do my process for all of the strings found within an email body - ie. if an email contains just one code, create one Trello card; but if an email contains four codes, create a Trello card for each of the four.
That is, there could be multiple outputs. I have no idea how this could work, since I think these workflows are only supposed to accommodate one action.
I could use some help getting over the hill. Thank-you.
David here, from the Zapier Platform team.
I'm glad you're showing interest in the code step. Assuming your assumptions (32 characters exactly) is always going to be true, this should be fairly straightforward.
First off, the regex. We want to look for a character that's a letter, number, or punctuation. Luckily, javascript's \w is equivalent to [A-Z0-9a-z_], which covers the bases in all of your examples besides the -, which we'll include manually. Finally, we want exactly 32 character length strings, so we'll ask for that. We also want to add the global flag, so we find all matches, not just the first. So we have the following:
/[\w-]{32}/g
You've already covered mapping the body in, so that's good. The javascript code will be as follows:
// stores an array of any length (0 or more) with the matches
var matches = inputData.body.match(/[\w-]{32}/g)
// the .map function executes the nameless inner function once for each
// element of the array and returns a new array with the results
// [{str: 'loYm9vYzE6Z-aaj5lL_Og539wFer0KfD'}, ...]
return (matches || []).map(function (m) { return {str: m} })
Here, you'll be taking advantage of an undocumented feature of code steps: when you return an array of objects, subsequent steps are executed once for each object. If you return an empty array (which is what'll happen if no keys are found), the zap halts and nothing else happens. When you're testing, there'll be no indicator that anything besides the first result does anything. Once your zap is on and runs for real though, it'll fan out as described here.
That's all it takes! Hopefully that all makes sense. Let me know if you've got any other questions!
Is there an easy way to get the opposite of a regex or do I need to build a new regex that produces the opposite of what I have?
For example, I use this regex to make sure I'm getting proper currency values -- without $ sign.
/^[0-9]+(\.[0-9][0-9]?)?$/
I want to now remove everything that falls outside this pattern. For example, if user enters letters or tries to enter two periods e.g. 7.50.6, I want to remove undesired characters. How do I do that?
I think you're going at this in the wrong way. First of all, trying to hide input error in such a way is a bad idea. If a user has to type a number and they put an extra dot, what tells you which is the good part and which is the bad? You're better off telling the user there's something wrong with their input.
But typically, you use a regex by specifying what it has to look like AND what are the significant portions you want to keep using capture groups.
This is a capture group: ([a-z0-9])#example.com; this is a non-capture group: (?:hello|hi).
In case of a phone number, all that matters are the digits, so you can capture them and accept multiple forms of in-between characters. Here's a simple one for a postal code:
([A-Z][0-9][A-Z]) ?([0-9][A-Z][0-9])
Then all you have to do is combine the captured groups. If present, the space won't be captured.
Find more examples on MDN.
I'm using form validator in order to validate some fields on my signup form. One of which is a telephone field for which I have prepared two regexes that will provide validation.
regexp: {
regexp:
>/(^01|^02|^071|^073|^074|^075|^076|^077|^078|^079)/,
/^((?!(012345|123456|234567|345678|456789|0{6,}|1{6,}|2{6,}|3{6,}|4{6,}|5{6,}|6{6,}|7{6,}|8{6,}|9{6,})).)*$/
message: 'The phone number is not valid'
}
My issue is that only one of those two will work, not both. Any idea how I could modify this such that they both work?
This regex will work, but I'd still suggest maybe finding a different way or set of criteria to validate. It's up to you though.
/^(0(?:[12]|7[145789]))(?!012345|123456|234567|345678|456789|0{6,}|1{6,}|2{6,}|3{6,}|4{6,}5{6,}|6{6,}|7{6,}|8{6,}|9{6,})/
This will ensure the number begins with the proper prefix and does not contain the sequences you've indicated.
You could combine the two like this:
/^(?=(01|02|071|073|074|075|076|077|078|079))((?!(012345|123456|234567|345678|456789|0{6,}|1{6,}|2{6,}|3{6,}|4{6,}|5{6,}|6{6,}|7{6,}|8{6,}|9{6,})).)*$/
Does seem like a kind of obfuscated way to perform some fairly simple checks to me, but to each their own.
if I want to validate the input of a <textarea>, and want it to contain, for example, only numerical values, but even want to give users the possibility to insert new lines, I can selected wanted characters with a javascript regex that includes even the whitespace characters.
/[0-9\s]/
The question is: do a whitecharacter can be used to perform injections, XSS,even if I think this last option is impossible, or any other type of attack ?
thanks
/[0-9\s]/ should be a safe whitelist to use, I believe. You do need to ensure that it checks the entire input, though; I think you mean /^[0-9\s]*$/.
Also remember, of course, that you have to validate it server-side, not just in the browser. Attackers can easily bypass JavaScript validation code.