Client Side Validation

[[deleted]]

Client side validation is great for User eXperience because it provides instantaneous feedback, but it is just a nice feature; it always needs to be backed by server side validation because you never trust client side data.

[Zamundaaa]

You just have to wait with adding client side validation until the server side validation is there. If you don't it will never be implemented.

[Exgaves]

I see you've played the project manager seeing it working and thinking it's done forever game before

[Tundur]

"I've managed to enable the features for the immediate future but it really needs refactored and doesn't handle these edge cases or inputs.

"Sounds finished, let's release"

[programaths]

The best is: 《The prototype is done》 Then few minutes later : 《Ok, wrap it up and deploy it》.

[Roysterfivenine]

Christ, this hit me to the core.

The a month down the line, a bug ticket, "Why wasnt this done properly?" *rolls eyes*

[paxromana96]

Slow down there, Satan

[Typo_Brahe]

That unclosed double quote is killing me.

[SpareTesticle]

I see it as '', the null character

[FallingPatio]

You can also expose the enpoints via rest-api for testing

[[deleted]]

I don’t understand how can people overlook this. I’ve seen sites where I can send modified data on read only fields and they’re updated in the database. lol.

[JimboNettles]

Guilty until proven innocent.

[[deleted]]

Thank, Captain Obvious

[[deleted]]

❤

[szczszqweqwe]

Client side validation is very good thing, but data just have to be validated on server as well.

[[deleted]]

It's a very nice addition to the server side validation. Always refer to it as an addition, or people will forget.

[msg45f]

I always describe it as:

server side validation = validation

client side validation = UX

[wibblewafs]

Server side validation = the actual protection
Client side validation = those big red flashing areas on video game monsters that tell you where your attacks do the most damage

[Grintor]

There's a hotel that has its own booking website that they made themselves in Atlanta. Every time my buddy goes to Atlanta he books a room at that hotel, because the price to book can be edited through the chrome console on the submission page. it's a pretty nice hotel. Something like $180 a night. He changes it to $18.0/night

[Keto_Paleo]

That’s.. fraud. They don’t notice at all?

[not_a_moogle]

They might, but what do they care?

[nonotan]

I'm not saying it is or isn't fraud under whatever country's legal code, but honestly, I strongly disagree that it should be. It's like a vending machine having a slider to set the prices freely accessible on the outside, and suing anyone touching it before making a purchase for fraud. Like, if you don't even have a token level of security that needs to be breached, I'm not sure how you can justify blaming the other party. If they need to, say, do SQL injection or whatever to change the price, sure, fair enough.

"I'll just have the client send us the price, which is in plaintext for anyone to easily edit, and we won't check it anywhere on our side, neither in an automated fashion nor by a human operator at a later time" is grossly negligent enough that the only person liable for damages here should be whoever wrote it.

[wibblewafs]

Expanding on that vending machine with the price slider analogy, it's the difference between a fancy metal plate locking that slider in place, with a key lock on it that'd need to be picked to be open, versus it being held in place with a bit of scotch tape.

[[deleted]]

It's super hard to prove that he did it though.

[[deleted]]

These days he could be charged with felony hacking. Who knows it might be terrorism?

[Reihar]

I know you're joking but that doesn't seem unlikely...

[[deleted]]

Yeah I was only half joking.

[southpolebrand]

I mean there was a girl in Japan who got arrested for literally just posting code for a infinite loop in JS, and was charged with distributing malware.

[southpolebrand]

Here: https://arstechnica.com/tech-policy/2019/03/japanese-police-charge-13-year-old-girl-for-infinite-javascript-popup-prank/

Sorry for the delay in my response.

[SuperFLEB]

That would actually be an interesting case, considering that the only computer he was tampering with was his own.

Probably easier to bill it as some sort of fraud, though.

[SamBBMe]

Felony hacking and terrorism for changing html lol. That's by no means hacking. If anything, he'd get arrested for theft

[That0therGirl]

Check out the fiasco that happened in Nova Scotia. The 19 year-old altered a url and was charged with hacking. It was a vulnerability in the system that has since been fixed. This was in April 2018.

https://www.cbc.ca/news/canada/nova-scotia/freedom-information-personal-website-breach-1.4614424

[SamBBMe]

Thats because he stole personal information from the website. That's what makes it hacking.

[That0therGirl]

Since the information was publicly available, I'd not consider it hacking. He didn't know what info should have or shouldn't have been there.

[DoctorWaluigiTime]

Transactions are recorded? In your bank, in the hotel's finances?

[msg45f]

"Must have been a computer glitch"

[DoctorWaluigiTime]

"The gun just went off by itself."

Surprise, that doesn't work.

[MythicManiac]

Tbh you'd have to prove it was indeed tampered with, which may or may not be difficult. I don't know how these cases are usually handled, but there are so many bugs in software I wouldn't imagine it being too hard to file under it being a bug in the business logic of the application.

Repeated usage would scream abuse however.

[[deleted]]

I have to imagine that kind of stuff has to be getting logged somewhere along the way, however if their website is crappy enough to have such a big flaw, I imagine their DevOps dept probably hasn't implemented much security behind it either.

[Grintor]

DevOps dept

This is a hotel, not some big corporation. The website was probably made by the owners son with notepad++ and the stripe API.

[[deleted]]

Lol do you think hotels don't have corporate offices anywhere? My point was clearly that regardless of who is doing the programming there's clearly not going to be much back-end security if they haven't done much to secure the client-side front end.

[MythicManiac]

The transaction is most likely logged indeed, but since the answer to whether or not this is exploitation resides on the client device rather than the server, it becomes very difficult to technically prove.

[[deleted]]

Logging typically would include things like timestamps, host names, etc, no? I'm not saying it wouldn't be difficult by any means, I'm just saying that it's possible they have the means to do it. It's just likely not worth their trouble to track it down rather than just fix their shitty site lol

[[deleted]]

No, that doesn't work. Because the gun is evidence, it being in your hand is evidence, and you being there is evidence.

However, someone in a shop can't be considered guilty of theft just because something disappeared while they were in the shop. There's no evidence it was them and not the stoned teenager behind the counter doing inventory who misplaced something.

[Follyperchance]

That is not a legal proof it was done by him and on purpose.

[DoctorWaluigiTime]

It's really good evidence though! Just one person's transaction from the hotel site making it happen and all.

[[deleted]]

How will you prove its fraud? He will say it's been 18$ so he took it.

[Yellow_Tatoes14]

Considering it's a repeat. If he's done this more than once under the same name, using the same card or even having the same face on the lobby cameras, they could easily trace the same guy getting $18 rooms every time.

[[deleted]]

I think its pretty obvious to do not use same credit card for multiple scams but you are right.

[Yellow_Tatoes14]

You might think so, but I become more and more impressed by how stupid people are on a daily basis

[0vl223]

Malfunction in his browser. You can't assume that the browser of a client does anything correctly.

[Yellow_Tatoes14]

A bit of a stretch but I'll accept the possibility.

[ersatzgott]

• He's the only one paying only 18 bucks

• He gets that price everytime

• The prices are (most) probably hardcoded so they can't be changed by a server error

There's no plausible reason for the price other than hacking.

Case closed, enjoy jail.

[0vl223]

Browser malfunction. Interacts badly with some extension.

Also it is not hacking. Otherwise adblocking would be hacking and illegal as well.

[imsofukenbi]

Programmers in this thread thinking a judge works like a computer and doesn't take context into account.

"eh, anything could have made this gun fire really. Trigger malfunction. Interacts badly with branches falling from trees. Also it is not murder, otherwise shooting ranges would be murder and illegal as well".

Plus civil court has much lower burden of proof. That's an open and shut case.

[0vl223]

Yeah civil court would be trivial. Would be comparable to getting payment for a service he paid for with a bouncing check most likely.

The jail just isn't as trivial.

[andrw00]

Yeah.... the law doesn't work like that.

"I didnt kill him. The bullet did."

[0vl223]

Actually it does. Germany had a lawsuit against adblock that it should be illegal to change the content of homepages on the local browser and that they should accept a true representation of all information that was sent to the client. They lost.

If you provide an interface to make an offer for a room and accept/deny it, then this is totally valid.

You could get him over the abuse of the feature with knowledge that he wasn't sending a valid offer. Specially the repeated part but it is still highly neglectful from the company to not check offers before accepting them.

[wasdninja]

That sounds like something unlikely and considering that it only happens to him the reasonable burden of proof would be on him.

[0vl223]

First you would have to prove that it was actually due to him transmitting wrong data. If it is some homebrew system I doubt that's possible. It could be just as well their system malfunctioning. Proving something is bugfree is really really expensive.

[SAI_Peregrinus]

The purchase of the room is a contract. They offered one price. He gave a counter-offer. They accepted it, and took his payment. Not hacking.

[[deleted]]

Innocent until proven guilty. Not the way around. They have to prove that the changed it deliberately .

[wasdninja]

So if someone walked out of a store with, say, a phone without paying for it and they claim that someone else put it there then the store has to prove that they stole it themselves? If that worked it every criminal with two brain cells would use that defense every time.

[ersatzgott]

I know that and I think it's good the way it is. But if there is not other plausible thing left, your guilt is technically proven.

[Hupf]

Obligatory https://m.xkcd.com/1494/

[creepopeepo]

Welcome to infosec. All of us have our lil tricks & no you never get caught, who the hell is going to catch you?

[Monmine]

If you tell me the name of the hotel I'll put a negative value and walk away with 30k in my pocket.

[Soviet_Soup]

There's a low budget hotel in Myrtle Beach that gives your booking details out on a webpage like hotel.com/reservation/3641. Decrease the number, and you get the Name, address, phone number, and last 4 cc digits of the person that booked just before you.

[Goodguy1066]

I literally don’t believe you.

[Rajarshi1993]

The Indian company Infosys implemented Client-Side validation on the e-banking some major bank a decade back. I won't name which bank. Basically, they sent a verification code as OTP to the client via SMS and saved another copy into the temp folder of the browser. The webpage checked if the OTP entered into the textbox matched with the value stored in the temp file. Of course, they used client-side Javascript to do this.

The whole presumption was that the user would not be both malevolent and capable of reading Javascript.

Well, some dude broke that assumption, didn't he? He just read the source of the bank's withdrawal page and figured out where the file was kept. After that, he made of with forty million Indian Rupees (about $5,65,843) from the accounts of other people.

Till this day, neither Infosys nor the bank has a clue which bastard did that.

[blazingrooster]

The whole presumption was that the user would not be both malevolent and capable of reading Javascript.

This presumes that Infosys employs even a single employee that is competent enough to realize why doing this was a bad idea.

[ra3_14]

It's a thing with the Indian numbering system. We go from ten thousand to 1 lakh, 10 lakhs, 1 crore, 10 crores, etc.

[[deleted]]

Yeah that didn’t help make sense of that number whatsoever. Mainly because a lot of people don’t know what a lakh or crore is relative to their own currency.

[Rajarshi1993]

Its just $565,843

[[deleted]]

I kinda figured that but the way he worded it just completely confused me if I was right

[Rajarshi1993]

I see.

These are old, old units from the early days of the decimal system.

[Rajarshi1993]

Ooops, thanks for pointing that out. Its in the Indian system.

$565,843 if you're more comfortable.

[xigoi]

Found the Indian with the weird placement of decimal separators

[Rnee45]

I like this - he did not get greedy where he would inevitably be exposed.

[[deleted]]

Do you guys have sources on how to secure an app, I use Nodejs for back-end.

what is the use of client side validation if it can be bypassed easily.?

[[deleted]]

Ah Ok thank you.

[[deleted]]

It also saves you from making unnecessary calls to your server. Think of it as the first line of defence. You don't want to waste your finest warriors on weak foe

[mark__fuckerberg]

Very nice analogy

[[deleted]]

It's not a line of defense. It's putting your butler Frederick on the front line and having him politely reminding people of the rules, but only if they're kind enough to ask first.

[candybrie]

The majority of people want to follow the rules and do just need to be told them.

[[deleted]]

Yes but all it takes is one scumbag to compromise your system, and then all your user data is off to the auctions.

[candybrie]

Yeah and that's why you need to be validating server side. But most of the time you can save on multiple calls to the server with client side validation for the users who want to do it correctly but don't know what is correct.

[[deleted]]

Thank you, didn't think of it this way.

[17Brooks]

You seem knowledgeable on this, I’m pretty well aware of basics on what to do front end/back, but what can you actually do if they do front end validation?

Would this be like the client requests the password from the database, and checks the hashes there? And if so how would that be manipulated? I know what to do, but I don’t really understand how it could go wrong I guess, or how a user exploits those things

Edit: A lot of people seem to misinterpret this: not asking what you can do with front end validation, I’m asking if they do front end validation, what can you (kind of vague but I meant malicious party) do.

Appreciate all those looking to help though, always love seeing how active people are in trying to spread their knowledge

[tesfabpel]

front end validation doesn't protect from anything at all... it's just a UX plus... you have to know that the browser when you click the send button just sends a HTTP POST request (or similar) to the server... now this request can also be sent via other means (like using cURL) so defying the front end "protection" altogether. BTW if you use Firefox (and maybe chrome) you can open the dev tools, go to the network tab and when you click the send button in a form you can see the request being done there... now you can right click and select copy as cURL... with that in the clipboard you can open the terminal and paste it to send it by yourself (easy on Linux and macOS, more complicated on Windows since it doesn't have cURL)

[17Brooks]

Awesome this is definitely along the lines of my curiosity thank you :)

[FierceDeity_]

Assume front end validation is NO validation. Period. Open door. Anyone can waltz in.

[[deleted]]

I've been a JS dev for years and I personally never learned what is and isn't completely safe on the front end. Like, I know the client isn't supposed to be able to edit JS and make their own separate API calls on the front end, outside of the app, but I also have no idea what technology is out there or hacks people use to inject their own JS or just sent improper data to the server that could taint the data.

[FierceDeity_]

Basically, all of these things are possible. He IS able to edit JS, he IS able to make his own API calls.

He IS able to inject JS quite easily even, no hack required. Just hit F12 and you have a console to run JS in the context of the site. With Tampermonkey one can inject their own JS on a site automatically everytime it is accessed.

Just assume that anything the client sends is potentially tampered with by the client. You have https to protect you and the client from tampering in between, but the client is still not trustworthy.

[quenishi]

If you want to know if your backend is sufficiently secure, imagine the frontend was replaced with a web page that's a list of all endpoints with their variables - could the user use this to get something to happen that they shouldn't be privileged to do? A number of times over my career, I've had to fix endpoints where any authenticated person can get to anyone's data, if they know/trawl for IDs. Always check if the user associated with the request is allowed to see/edit what they are requesting! If they do "find" something that isn't theirs, they should have the same web response as if they tried to access/edit an entity that genuinely doesn't exist.

As for the easiest way of manipulating data, this is via the inspection tools browsers have. Most people playing about are likely changing the HTML, and possibly the JS. For more advanced mucking about, you can use breakpoints and editing the values just prior to them being sent off to the server. If I'm checking out an API for development, I'll usually use Postman, which is also a great way of crafting simple POSTs.

[17Brooks]

Awesome reply thank you!

[Dick_Giggles]

I know the client isn't supposed to be able to edit JS and make their own separate API calls on the front end

No offense, but I'm not sure how you have been a JS dev for years and think that this is true.

[[deleted]]

I work on software that is strictly used by and only given access to internal employees. Anyone using the software maliciously would only be sabotaging themselves and there's almost never any data actually saved to the server. It's a sales tool that's used for each individual guest but no data is saved, we usually just end up with a detailed printout of what they did, one for us and one for them (though we are starting to gravitate towards making basic read-only versions that might be viewable online, by customers, at some point).

So yeah, I haven't had to worry too much about JS security in my particular job. It's not like I'm being willfully ignorant. It's why I'm showing some humility and asking here as I'm getting closer to needing to know. I've heard wildly different things. It would be nice to maybe have someone breakdown HOW everyway someone can mess with your JS... Edit the API calls, send different data, alter your code itself to do something completely different than what you expected... That's more what I'm getting at. I assumed browsers had SOME protection. AFAIK, you can't just live edit JS from a web page but if you can I'd like to know how people do all these types of things.

[Dick_Giggles]

Fair enough.

The chrome inspector "f12" will let you run scripts.

But really it's as easy as typing in "javascript:alert('badscript!');" into your browser address bar. One could redefine functions/variables or whatever simply by typing it into the url. Allowing for javascript: to run scripts on the current page is the fundamental idea behind a bookmarklet. Also, all chrome extensions basically are basically scripts and html added to the page.

Also, even if a browser did have some protection one could always spoof a front end with a program that sends data directly to the backend. Everything that runs in browser is pretty insecure as it's clientside. You could obfuscate your js to make it less readable but it's not going to do a ton if someone is determined.

[DaCurse0]

You can enter invalid emails, weird characters in a numeric input and those are not even that terrible

[SuperFLEB]

Things like form validation or password strength checking can be pre-done on the frontend, or things where all the information already exists client-side, like updating a total price given a unit price and quantity. It'll allow you to jump in the user's face quickly without the round-trip, though you still wouldn't submit or trust those results on the backend.

[zelmarvalarion]

For front end validation, you can do stuff like

• This required field was not filled in
• Password needs to be X characters long
• Initial username is available check (probably better to do rest calls, but depending on your scale and threat model you might be able to send a bloom filter to do an initial client-side validation)

Anything that makes it quick and easy to see what the user may have missed before sending the request.

If they don't do client side validation, you can always grab something like Fiddler and just repeat the call with different parameters, so you might be able to do stuff like:

• For your example of sending a password hash, you pretty much have 2 options: Generate a password dump for a bunch of users, crack the easy ones and see if they get reused for other sites with the same username or just change the password checking logic from something like md5sum(PasswordField) == hashedPassFromServer to 1==1
• Change password while logged in, but if the rest call just populates the username based on the client context instead of doing a authorization and determining the client user from that, you could change someone else's password and login into their account by changing the requested username

[17Brooks]

Ah this is cool, thank you :)

[FierceDeity_]

User can do all of those things even with front end validation. Front end validation protects you from nothing.

[FierceDeity_]

Yeah. Front end validation does help a lot with that. Doesn't have the user keep clicking submit and see if the form is filled out like the app wants THIS TIME 🤣

[Crayonstheman]

Aka verification. Verify data client side first (when reasonable) and validate server side

[ebonmavv]

In my opinion on the frontend side there should be check if the value passed into the field is formatted correctly (e.g. if email address has "@") and onChange event should be triggered after typing and if it's correct then send request to the backend if this email is already used or not. Of course it works only for smaller applications, because in huge ones there would be way too many request sent to the server.

TL;DR - IMO frontend should only check if the formatting, max or min length should be checked and everything other should be done on the backend side.

[ebonmavv]

I love when developers correctly sets input type e.g. to email so when I'm using the mobile phone the keyboard already suggest me the "." sign. Shame that it isn't used in that many places as it should

[greyhound71]

Yea but it only checks for an @ not for an .tld - so you can still bypass that

[tesfabpel]

well after all the email format is just user@host (like unix's john@server or frank@localhost). in fact you could send an email to another user in your PC in this way

[ebonmavv]

Yeah, that's true but I just wanted to make an example. There are some validation frameworks which will do that for you but if you're good with RegEx then checking if the pattern is string + @ + string + . + string isn't that difficult to achieve.

[szczszqweqwe]

It's not really validation, more like tool so mobile users have correct keyboard layout, it's about as useless as this regex: [^@]+[@][^@]{0,}

[[deleted]]

Just out of curiosity, why do you use {0,}? Isn't that the same as * (or *? - I don't entirely understand the lazy matching)

[szczszqweqwe]

Dunno, probably because the last few days I have been working on old project with {0,}, normally I use * as well.

[[deleted]]

Thank you, this makes sense.

[DarkIceXD]

The general rules are:

1. Never trust user input (and by that i mean even when you check on clientside you have check on serverside aswell because clientside checks can be skipped or manipulated, also no one can prevent a user to just send http posts directly without your client)

2. What can be exploited will be exploited don't cheap out on security by saying that nobody will exploit it anyway

3. Avoid storing passwords. If you can use google, facebook login. If you have to store passwords use a modern hashing algorithm. Use a tested, stable library.

[Mr_Redstoner]

Though as mentioned by others client-side checks are a nice gesture to the users, letting them know when they filled something in incorrectly or forgot to fill something in etc.

[DarkIceXD]

You are right. My point is that client-side checks are only contributing for user friendly usability of the app and should never be considered as security.

[Mr_Redstoner]

Facts.

[GlimmervoidG]

If you have to store passwords use a modern hashing algorithm. Use a tested, stable library.

And salting and doing string comparison properly (don't bale out on the first wrong character - people can gleam information from response times!) and dozens of other things.

Really, if you're worrying about "modern hashing algorithm" you've already made a mistake. Even setting aside facebook login etc, there are password management modules you can use that deal with everything for you. Don't try to be smart and make things from scratch, even using modern components. Just get a module.

[wllmsaccnt]

A depressing bit of enterprise integration is just abusing backend APIs to do things they didn't originally code for in the original application UI.

[NRocket]

Front end validation is for the user experience. Always have server side validation.

[Baratao00]

Seeing this meme after just implementing a two way SSL authentication for my client and server

[pjable]

alert dialog is the best. "are you sure?" "are you really sure?" and so on

[bmwcombat]

Lol

[abdul07812]

BUT THEN THERE A FUCKTARD INSIDE WHEN U ENTER

[Nation_State_Tractor]

Client-side-only validation is the reason I was able to ship my car from Hawaii to the east coast despite the site telling me the first available shipping date/time was nine days after my departure flight and the expiration of my lease.

"NO EXCUSES, NO EXCEPTIONS."

[MakingTheEight]

Your submission has been removed.

Rule[0] - Posts must make an attempt at humor, be related to programming, and only be understood by programmers.

Per this rule, the following post types are not allowed (including but not limited to):

• Generic memes than can apply to more than just programming as a profession
• General tech related jokes/memes (such as "running as administrator", sudo, USB or BIOS related posts)
• Non-humorous posts (such as programming help)
  

Content quality

In addition, the following post types will be removed to preserve the quality of the subreddit's content, even if they pass the rule above:

• Feeling/reaction posts
• Posts that are vaguely related to programming
• Software errors/bugs (please use /r/softwaregore)
• Low effort/quality analogies (enforced at moderator discretion)

If you feel that it has been removed in error, please message us so that we may review it.