Mobile Devs Making the Same Security Mistakes Web Devs Made in the Early 2000s (bleepingcomputer.com) 96
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.
Re: Very legitimate reason for this (Score:5, Informative)
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.
Re: (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:3)
TFA was apparently written specifically with you in mind.
Re:Very legitimate reason for this (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
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!
Re: (Score:2)
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.
Re: (Score:2)
Anybody competent does it. Seriously.
Re: (Score:1)
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 sma
Re: (Score:2)
FTFY
Re: (Score:2)
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?
Re: (Score:2)
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 pro
Re: (Score:3)
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 someho
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Wh
Missing The Forest (Score:2)
...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 summe
Re: (Score:2)
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
Re: (Score:2)
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.
Sorry, these are not growing pains (Score:2)
Re: (Score:2)
Well, since it is a growing body of incompetent developers, it is at least a growing pain. The ever more complicated field of half-assed "frameworks" and intransparent mechanisms used makes things worse. The sheer amount of over-complicated, non-intuitive, "magic" technology used in the web and app fields is absolutely staggering and will never be secure.
Re: (Score:2)
If there's one constant in software development, it's that nobody learns from the past. It's not a new problem either.
Client Side AS WELL AS Server Side (Score:5, Insightful)
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.
Re:Client Side AS WELL AS Server Side (Score:5, Insightful)
You need both. Client side is for sanity checking, just so the obvious security issues don't make it to the server and take up server resources (bandwidth, etc.). For sense of security, everything needs to be checked at the server side, as -nothing- should be trusted. Sorry, Bobby Tables.
Re:Client Side AS WELL AS Server Side (Score:4, Insightful)
Client-side: Usability.
Server-side: Security.
Re: (Score:3)
Much of that is inconsistency with HTML5 events: both in terms of the spec but also the implementation. For example, some controls have "click" events that are really "focus" events. Some have "click" events and "changed" events and others have both. This is why something might work with a mouse but not with a keyboard, or with a mouse but not a touch screen, or in one browser but not another.
Re: (Score:2)
I would suggest ditching direct reliance on HTML5 until they get the glitches out. Let other shmucks be the guinea pigs.
It took about 15 years to get pre-5 HTML (mostly) right, or at least predictable enough to work around its warts. I don't expect 5 will be significantly quicker.
People fear keeping up with the Joneses so much that they follow the Joneses off cliffs. There's a reason I kick the Joneses off
Re: (Score:2)
I apologize, I didn't mean to imply that these problems only applied to HTML5. These problems still apply to pre-5 HTML as well. Really, this has been a problem since JavaScript's inception.
Not Just Mobile Apps (Score:2)
Hasn't Panera Bread just recently [slashdot.org] suffer from a similar issue?
License sotware engineers like actual engineers (Score:3, Interesting)
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.
License engineers have the power to tell thereboss (Score:2)
License engineers have the power to tell there boss NO THAT IS UNSAFE.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
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'.
Re: (Score:2)
Surely that last one is the province of MDs?
Re: (Score:2)
Sorry.
Punchline: Whore: 'That's not my navel, that's my colostomy.'
Sorry, again. /Canadian
Re: (Score:2)
Most people make the mistake the other way round.
Naval gazing:. #Sitting on the dock of the bay ... watching the ships come in ... /#"
Re: (Score:2)
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.
Re: (Score:2)
A PE would be professionally responsible to tell his boss: 'No, that would be insecure, can't do it.' The NSA wouldn't hire software PEs.
I bet the NSA doesn't have lawyers on their hacking teams, because they carry extra responsibilities, they are a liability.
They're there, but 'no nothing, see nothing', not even if you have apple strudel.
Re: (Score:2)
You're picking things apart starting too high up in the stack.
Does the government require buildings be built with secret back doors or faulty locks (so the occupants' security measures can be easily bypassed by anyone who knows the trick) or that building material manufacturers make bricks and lumber to shoddy specs so that new holes can be poked through structures at their whim?
Why, then, should it be able to require that software on which peoples' lives and livelihoods depend be similarly compromised?
Re: (Score:2)
Re: (Score:2)
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.
Doctors and Lawyers exist. And they go through extremely lengthy and difficult licensing/education regimes. And they provide plenty of examples of people who did exactly what you claim they would not.
Re: (Score:3)
That's what ratings are for - your app store is more effective than any state licensing board. Though to be fair, liability should not be able to be waived with an EULA.
Anyway, software design isn't at all like structural engineering. Gravity is consistent. Winds have a 100-year maximum, and you can build a seismic safe building anywhere if you want to pay for it and avoid outlier risks.
With software, you have a building. The earth may suddenly turn to quicksand, your building may be attacked by dinosa
Re: (Score:2)
What's needed is some unbiased pool of experts who can evaluate software, and give it their stamp of approval that it's passed attacks along known vectors like SQL que
No Matter. AI fixes everything! (Score:1)
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!
Well yes, because that's a new "generation" of (Score:2)
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.
Presumptious (Score:2)
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.
Re: (Score:2)
You don't need Perl for that. Even PHP can do it!
Re: (Score:2)
It also presumes that the mobile devs are writing the backends. Otherwise how is it the mobile dev's fault that the backend isn't validating data?
Mistakes Web Devs Made in the Early 2000s... (Score:4, Insightful)
Re: (Score:2)
Still the same incompetents that have no business coding anything connected to the Internet.
Cretinization of coding (Score:5, Interesting)
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.
Truth (Score:2)
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.
Relevant (Score:2)
https://xkcd.com/327/ [xkcd.com]
Better yet (Score:2)
Stop forcing mobile users to download your "app" in order to use services and product (VENMO!).
eh (Score:2)
Particularly with mobile, it often makes sense to validate both places. Avoid a network call if you can.
Server lag (Score:2)
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".
Re: (Score:2)
Maybe they should be validating in both places. That way you get responsiveness on the client and security on the server.
Web devs still inept (Score:2)
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.
Similar outcome due to similar incentives (Score:2)
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 o