Slashdot Mirror
Mobile Devs Making the Same Security Mistakes Web Devs Made in the Early 2000s (bleepingcomputer.com)
Catalin Cimpanu, writing for BleepingComputer: Mobile app developers are going through the same growing pains that the webdev scene has gone through in the 90s and 2000s when improper input validation led to many security incidents. But while mobile devs have learned to filter user input for dangerous strings, some of these devs have not learned their lesson very well.
In a research paper published earlier this year, Abner Mendoza and Guofei Gu, two academics from Texas A&M University, have highlighted the problem of current-day mobile apps that still include business logic (such as user input validation, user authentication, and authorization) inside the client-side component of their code, instead of its server-side section. This regretable situation leaves the users of these mobile applications vulnerable to simple HTTP request parameter injection attacks that could have been easily mitigated if an application's business logic would have been embedded inside its server-side component, where most of these operations belong.
In a research paper published earlier this year, Abner Mendoza and Guofei Gu, two academics from Texas A&M University, have highlighted the problem of current-day mobile apps that still include business logic (such as user input validation, user authentication, and authorization) inside the client-side component of their code, instead of its server-side section. This regretable situation leaves the users of these mobile applications vulnerable to simple HTTP request parameter injection attacks that could have been easily mitigated if an application's business logic would have been embedded inside its server-side component, where most of these operations belong.
These are idiot developers.
There's nothing wrong with Client Side validation. It lets you prompt the user to correct their mistakes. Of course, this client side validation shouldn't be trusted when the data gets to the server-side. You need to check it on the server side also. Client Side verification has it's place in any good web application.
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
If you're doing validation to help the user, that might be fine. But if you're validating for correctness or assuming data has followed all your validation rules, then client-side validation is worthless.
I don't think Web developers necessarily learned the lesson very well. Javascript-heavy (client-side JS) web apps with insecure RESTful backend also suffer from the same issues. I'm seeing a lot of those recently.
Hasn't Panera Bread just recently suffer from a similar issue?
It's funny how the media speaks of "software devs" like they're a cohesive body of professionals.
In fact it's largely a bunch of people straight out of a coding bootcamp in over their heads with titles like "senior full stack developer" who think they're 10x rockstars because they can code Hello World.
Managers love these folks because they work for peanuts + inflated job title. Need someone to cut corners to meet a deadline? Or to take some unethical business idea and build it into software? These are your guys.
Find me someone who's worked his ass off getting licensed to practice their profession who's willing to put their livelihood, license, and professional liability insurance premiums on the line to save a couple bucks here and there.
It's time for software to mature like other niches have- plumbers, electricians, structural engineering, for example. You DIY your projects around the house until you burn it down or the building inspector condemns it, and you should be able to do the same with your own computing hardware until you let the blue smoke out of it or it simply grinds to a halt under a malware infestation. But if folks are going to build apps for money they should be certified and accountable for ensuring their work meets reasonable standards.
TFA was apparently written specifically with you in mind.
The singularity AI will fix all that... BIGLY! Just dont try to buy a cake.. its against our beliefs to sell YOU anything.... FREEDUMBS 4 ALL!
License engineers have the power to tell there boss NO THAT IS UNSAFE.
If only there was a way to do the validation in both: on the client side for fast response and on the server for security. That'd be just dreamy!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
people. Mobile apps are now the area inexperienced people will start writing their first public code. Before that it was web design and before that it was writing Windows desktop applications.
Some of those people will then grow up and most likely leave that field, just as the mobile app environments are as shitty as the web design environments or the Windows desktop application ones.
This presumes that web devs don't make these mistakes anymore.
They make this sort of mistake all the time. The difference is that any big, recognizable name that failed to fix this ultimately failed for one reason or another. Look at smaller sites or internal services at companies that are home grown, they are still chock full of this stuff.
XML is like violence. If it doesn't solve the problem, use more.
Newsflash, webdevs still make these same mistakes. Often times there is little or no distinction between a "web dev" and a "mobile dev" in reality.
Well, that's what we do in our group (info withheld—not here to pander our things).
We use a file name validator object we pass around to a multitude or places in the app that enforces format of such things as file names.
But MITM attacks wouldn't be prevented by this and the first line of defence is server side: it will not accept unvalidated inputs.
Ease of use is enhanced by having client side verification telling the user exactly what's wrong with their input.
More and more coders. Still the same (very small) number of people that can learn to code well. What do you expect? And no, coding well is not something everybody can learn. Might as well claim that anybody can be a PhD level Mathematician or a competent brain surgeon. Not so, not so in the least. And that utterly mistaken and completely unfounded belief is at the root of the problem.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This is absolutely true. The easiest way to see this is to connect your phone through a captive portal which injects content (such as ads) into web pages. Then watch as they start showing up in apps instead! And if you think this is just bottom-tier, b00by devs, think again. For the first two years or so of Instagram existing, this was an issue. I only discovered it on accident one time when using in-flight WiFi, and had the airline's advertising at the top of my Instagram feed inside of their Android app. Since the Facebook acquisition though, things have tightened down quite a bit, but this just goes to show that it doesn't matter what scale an app is, oversights and fuckery will happen.
You should always have both.
Client Side and Server Side validation.
Client Side, can do a lot of work, tell you what is wrong, make sure lengths are correct get rid of bad characters...
The Server Side still needs to be the last line of defense. If there something wrong, wrong length bad characters, missing fields. It should reject the entry of the data into the system and at least return a general error saying it didn't do it.
In terms of hardware requirements. Most validations take such a small amount of processing, that you will not notice it on the hardware, and the end user may get a fraction of a millisecond deference in wait.
The excuse that it will effect hardware requirements on the server, may work for your boss. But technically it is just an excuse to be lazy.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
The average attacker is dumb. But one non-dumb one can do a lot of attacks, especially with the help of automation. You have been competently attacked when you only notice months or years later or not at all.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
If you're doing validation to help the user, that might be fine. But if you're validating for correctness or assuming data has followed all your validation rules, then client-side validation is worthless.
Agreed. Someone can always sniff your APIs and try to attack your web interface, but you ought to validate inputs on client side just for the sake of your customers. The client app should not trust the user to input data correctly and the server should not trust the client to do so either. Don’t trust anyone. It saves your customers waiting for an error response from the server if you can easily determine they input something incorrect.
Indeed. Those that think reducing the need for server hardware this way is acceptable should be banned for life from coding anything. It does not get much more stupid than this when security is a factor.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Anybody competent does it. Seriously.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
That leads to things like Node.js, where you can use the "same" programming language on both the client and server side. Of course you then end up with developers who only know javascript, and they go around trying to recreate everything in javascript, or they create some clunky Framework that "solves" the validation problem by pushing complex libraries onto the client, which normally requires extensive testing yet it never seems to happen.
The truth is that client validation and server validation have a small area of overlap. You can check the data type on the client, and you absolutely have to check the data type on the server, and you can check field lengths and do sanity checks, and you can use some of the same code to do this on both the client and the server. But server side validation requires additional code to get the errors back to the client, so it is already a different beast. Then you might need to add some monitoring and logging tools on the server side, useful to detect penetration attempts. Pretty soon it doesn't matter that you are using the "same" language for both client and server coding, because the idioms are different and require different strategies.
The client side is like a screen door. You may be able to lock it, but locking the screen door is just telling people to use a different door, not actually doing anything to stop them from getting in, especially if you leave the door behind it open.
Javascript can be stopped or changed on the client.
Apps that do a system call to a server can always be packet sniffed and traced.
Programs need to be designed in a way the developer will not be able to get into the application.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
You'll find clusters of PEs everywhere there are lives hanging on mature engineering. Aircraft, Automotive, Power, Navel as well as Civil and others I'm no doubt forgetting.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Even more to the point, the two should use the same exactly library for validation so that there is never a disagreement about what constitutes valid input. Failing that, one of the two should be designated as a 'reference implementation' and have the source & unit test suite shared so it can be reimplemented exactly.
You'd be surprised how often mobile/server teams don't even have read-only access to each other's actual source repository. It's like someone imagined that keeping them in dark would somehow be beneficial.
You can't usually get a building permit without licensed engineers' stamps for structural, mechanical, and electrical. (Sometimes only an Architect's stamp is required, and for simpler jobs, maybe only a contractor's license.) However, the majority of the engineers doing the actual work are not licensed, but are rather working "under the direct supervision and responsibility" of the licensed engineer. This often means the person stamping the drawings has only a vague knowledge about the details of the design. Because of that, I've often said that a PE is a license to hire other people to do the work - but, of course, that's an exaggeration.
https://xkcd.com/327/
Fat, drunk, and stupid is no way to go through life, son.
Stop forcing mobile users to download your "app" in order to use services and product (VENMO!).
09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Are you dumb, or trolling? AC, so I'll guess troll. You ALWAYS need server-side validation. Bad actors won't use the client -- they will use telnet, curl, or a million other tools. Client-side validation will save some load on your server from honest people like honest mistakes -- no need to round-trip that data just to find that they left the '@' out of an email address, or missed a digit in a credit card number -- but for the ACTUAL data, you can ONLY trust the server to do the validation before saving.
What you're saying is like saying "we don't need police to enforce traffic laws -- we have signs saying what drivers should and shouldn't do."
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Particularly with mobile, it often makes sense to validate both places. Avoid a network call if you can.
FTFY
Sent from my ASR33 using ASCII
two academics from Texas A&M University, have highlighted the problem of current-day mobile apps that still include business logic (such as user input validation, user authentication, and authorization) inside the client-side component of their code, instead of its server-side section.
Maybe they want their app to be responsive and not spin waiting for the server to respond with "invalid input".
...For the trees.
For heavily used apps, leaving the validation client side can result in substantially lower hardware requirements on the server side.
There's a much more fundamental reason; Human Nature.
In general, the same type of people will approach the same type of problem in a similar way, including all the attempts at short-cutting, offloading, etc etc.
One can observe this phenomenon writ large in history, as people fall for the same ideological/political promises of Utopia again and again every few generations. A pioneering rock band of the 1960s called "The Who" had a famous song named "Won't Get Fooled Again" in which they summed this phenomenon up with the line; "Meet the new Boss, same as the old Boss". (BTW, if you've never heard The Who, do it. Do it now. Read comments later. Thanks optional but welcome :) )
Strat
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
First, validation is not exactly a large amount of server-side processing. Assuming your server is not a 386-SX
Second, you could do validation in both places. The local rejection would speed up the responsiveness to your users since there's no round-trip involved, and you'd also block various attacks that are sent to the server from something other than your client....especially since your server validation needs to cover things your client-side does not.
But that means keeping two sets of validation code in-sync. Which is harder than just doing it on the server.
Client Side, can do a lot of work, tell you what is wrong, make sure lengths are correct get rid of bad characters...
The Server Side still needs to be the last line of defense
Your server needs to run the client-side validation too. A request may not have come from your client, or your client may have been compromised such that it does not run the validation.
And yet buildings fall down and airplanes fall apart mid-flight.
I'll compare Linus's competence with that of a PE any day. Neither are perfect, but some magic certificate wouldn't make Linus* any better at what he does.
* or any other quality software developer
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
But most companies have a few PEs around to do the necessary sign-offs. The other engineers just need to know who these people are.
The article didn't indicate that they attacked the APIs.....they merely looked at the signatures. Just because the API looks like it can be hacked, doesn't mean it doesn't perform the necessary validations server-side ALSO.
Web developers are still doing a bad job. They fail to filter out unnecessary characters and reject perfectly reasonable input. Telephone numbers are a classic web dev fail. All of these should be valid:
(508) 999-1010
1-508-999-1010
5089991010
508-999-1010
and more.
Credit card numbers, dates and others are also major fail points.
Surely that last one is the province of MDs?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Implementing secure protocols takes development time and knowledge. Time equals money: either more developers are needed or more development time (i.e. the shiny new product/version comes out the door later).
When eye candy sells better than some footnote about security in an advert, then guess which qualifications will be in demand from developers and which parts of a project will get more development resources allocated (time, qualified developers)?
OTOH the costs of even a major security blunder is a bit of bad press that'll soon be superseded by the next big story.
Now imagine you're the controller for the project, what would be your recommendations with respect for allocating resources in development or qualifications demanded when hiring new developers?
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Indeed. If they are using different technologies, they should just share the set of test vectors used for unit testing.
But in the case where it's a client/server application both written in C#/Java/..., then indeed there's no reason that both sides cannot use the exact same library.
Sorry.
Punchline: Whore: 'That's not my navel, that's my colostomy.'
Sorry, again. /Canadian
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Linux is not a RTOS. Don't put it in 'human life critical' applications. There is such a thing as a PE in 'software'.
No doubt Linus could build a RTOS, if he wasn't busy. But he hasn't yet. Likely wouldn't want to deal with the highly formal development process bullshit involved. Code checkin is like a square dance, no step of which involves 'cuss your partner'.
There are stripped down distros that make the RTOS claim. But 'kernel mode drivers'.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
Most people make the mistake the other way round.
Naval gazing:. #Sitting on the dock of the bay ... watching the ships come in ... /#"
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Well. there's something to be said f or consistency.
Imagine you have a two-tier system where then front end's done in some retarded offshoot of VB and the backend's done on some retarded version of perl? Where's the bug?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."