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.

Comments

Client Side AS WELL AS Server Side

[Jason Levine]

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

[ctilsie242]

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

[gweihir]

Client-side: Usability.
Server-side: Security.

Re:Client Side AS WELL AS Server Side

[MobyDisk]

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: Very legitimate reason for this

[reanjr]

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.

License sotware engineers like actual engineers

[llamalad]

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.

Re:License sotware engineers like actual engineers

[bill_mcgonigle]

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 dinosaurs, the people in the building are usually trying to set it on fire, and the people who own it will never spend one cent on fixing any problems that appear. That and meteors.

There are heuristics for how to deal with these problems, but they're not entirely known at this point. AI testing might be one tool that will help us along, but please stop trying to pretend that software development is just another branch of engineering. "I wish X were better so X is just like Y, and by golly the government needs to regulate that" is just ... so derp. Let's solve the problems instead, over time.

Re:Very legitimate reason for this

[glenebob]

TFA was apparently written specifically with you in mind.

Mistakes Web Devs Made in the Early 2000s...

[asylumx]

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.

Cretinization of coding

[gweihir]

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.

Re: Very legitimate reason for this

[jittles]

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:Very legitimate reason for this

[gweihir]

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:Very legitimate reason for this

[Wrath0fb0b]

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.

Re:License engineers have the power to tell thereb

[bill_mcgonigle]

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