Front-end safety is paper tiger, bluffing

The article comes from the front-end black hole, the author of the top rock

In some cases, there has recently been a very hot question: Can the front end limit user screenshots?

As I looked at the question, I thought the questioner should be a budding, or irrational, product manager or SB leader. Because here's a very straight answer:

No matter how bull's technical means limit the software screenshots, users simply pull out their phones to take pictures of the screen.

This question, really shows that everything is front-end security, in fact, are paper tigers.

Next, I combine a few scenarios I've encountered to talk about some of the pseudo-front-end security requirements I've encountered since doing the front end.

There used to be those security needs that were sent back

In recent years, Internet data leakage is very frequent, my last company is doing financial loans, very much emphasis on data security, these two years also did a lot of security needs.

Front-end data desensitization

Front-end data desensitization is a very common requirement, especially in today's era when privacy is being sold so rampantly that many companies are starting to pay attention to these details, the most basic of which is data desensitization.

Data desensitization, is the user's private information, with some means, so that this information has a certain degree of identification, but can not be accurately obtained, such as:

It's usually our common data desensitization format, and I call him 数据马赛克 W hether the front end can do it or not, it can certainly be done, and a regular with a String.replace method is done. But if the product lets us achieve this demand, we will certainly refuse, because the front end to do data desensitization is 被单里眨眼睛 - self-deception.

At the end of the day, a person with a little BIT of IT common sense, if you want this data, take it directly from the request, why copy it from the page.

So data desensitization this kind of thing, must be handed over to the back end to do, from the source to start desensitization.

Maybe some of the later scenes, some of which are desensitization data, will be used again at the front end. For example, list data desensitization, to the details / form editing operations before the need to de-sensitization, then according to the ID to send another request to obtain pre-desensitization data, and then the interface call to do 权限限制和日志记录 so that the use of sensitive data is relatively safe.

Is form verification for safety?

When we do forms, we often do checks on data formats, such as mailboxes, phone numbers, bank card numbers, and even some very complex linkage checks.

Is the front end checking for safety?

There may be a little bit of meaning, for example, we used to check the input against XSS But now the front end of this format check, more is to: improve the 提升用户体验 enhance the 提升用户体验 enhance the 提升用户体验

First, remind and guide the user, how to enter; second, if the user input half a day, the front end is not verified, directly to the background, the background found the format is XSS攻击 SQL攻击 and then prompt the user, this is a very time-consuming and unprofessional interaction experience;

The data report is watermarked

Page watermarking, in fact, in the front end is very common, such as 钉钉 企业微信 group chat is watermarked, many online picture editing tools are also added, such as my commonly used picture monster, you want to white, he will give you a watermark:

And then we have some lists, because of operational needs, some data can not do data desensitization, so the leader said, the front end can do a watermark, let the data security point: to prevent operators do not deal with the problem according to specifications, private screenshots. So when I saw the question, I was particularly glad I didn't do it: 限制用户截图

In my personal experience, there are three levels of front-end watermarking:

• With CSS background watermarking, simple and rough, you can cheat a little liberal arts operation. B ut a slightly more knowledgeable person knows to block the watermark through Elements edit panel. It's so-called you add simple, others remove more simple.
• The JS orientation implants the watermark dom node, which is slightly more complex than the previous one, but is still shielded by Elements edit panel, just think more and take more steps.
• Final solution: Service side watermarking to generate 列表图片 to achieve ideas and graphic monster sites consistent. H owever, this operation is simple to describe, the implementation is very complex, need to consider 投入产出比 I t is possible that you may wonder why the service side is watermarked to generate pictures, rather than the front end itself generated by canvas?
  • First, as mentioned above, access to sensitive data through requests is inherently unsafe;
  • Second, JS itself is unsafe and tamperable;

JS can be tampered with

I've said over and over again that front-end security is a pseudo-requirement, and you may not believe it. B ut if you know that JS is 可篡改 you understand why. We're always talking about JS vilification, but vilification is more about reducing the size of the package, to some extent, making the published js resource less readable, but it's hard to be unreadable.

Next, try what JS can tamper with

Real-world drills

• Step 1: Chrome downloads and installs Header Editor plug-in

• Step 2: Find a target site and a JS resource that you want to tamper with. Here I take the jquery resource (js.tuguaishou.com/js/jquery-1.11.3.min.js) reference to my commonly used mapping site as an example;
• Step 3: Copy the code with the editor, enter what you want to tamper with, I just add a console output here, and then locally start a static resource service

  // ...
  console.log('do some change, ho ho ho');
  var c = []
    , d = c.slice
    , e = c.concat
  // ...

• The fourth step, using plug-ins to redirect the static resources of the site, I am here to use the local jquery instead of the original site, save the configuration and start that rule;

• Step 5: Strong brush browser, so that agent resources take effect, when you see the request is marked as 307 response, the tampering takes effect, and then look at console, there is the corresponding output;

At this point, a complete tampering is complete. But this tutorial is not to let you use this method to do some XX things, but just let you understand that because of JS tampering, we do website design, you need to always think about code security things, 能做不代表可以做

Share an interesting story

At the beginning of the year, the former company to do a large system integration: is the two subsidiaries each have their own rights system, and then the capital favors the party in favor of the advantage (in terms of system design, our permission system design is more professional), abandoned we have to change our existing system, to connect each other's system.

This in the middle because of off-site communication problems, the other side began not to say the rules, and then the docking person will be our cleaning and reorganization of the data into the database. L ater due to the need to modify some data, the website page prompts us to import data key format is not correct, and this key, and was set to read-only, which went to a dead end. Then communication can delete the database data re-import, the other side ten thousand reluctantly, let us delete on the site and then add data, that is more than 200 data ah, insult who????

This really annoyed my colleagues, and then tried the above trick, looked at the other party's JS, the agent and then submitted, successfully !!!

Know each other amateur, but did not expect such amateur: only in the front end made restrictions, the service side did not verify.

This case reminds us that the front end is focused on interaction, the service side is focused on Say no!!! and JS is tamperable; Also tell us to do technology, modesty, can help as much as possible to help, be a good person.

epilogue

And the destruction of a bunch of decadent, I hope you will be useful for future needs review and program design. I s front-end security important? s ignificant. I s it appropriate for the security of the website to be handed over to the front end? It's not appropriate.

The above is W3Cschool编程狮 about the front-end security is paper tiger, bluffing with the relevant introduction, I hope to help you.