预防xml注入漏洞攻击_预防性编程-漏洞发生前如何修复

预防xml注入漏洞攻击

by Kurt

由库尔特

福尔摩斯(Sherlock Holmes)本来是个出色的程序员 (Sherlock Holmes would have been a brilliant programmer)

错误是不可避免的。 (Bugs are inevitable.)

It is quite normal to spend more time debugging than you spend writing actual code. If you are learning to program and you absolutely hate debugging your own code, stop now.

与编写实际代码相比，花更多的时间进行调试是很正常的。 如果您正在学习编程，并且绝对不喜欢调试自己的代码，请立即停止 。

Find a new hobby or trade that you enjoy. Otherwise, you will soon discover the true definition of insanity: debugging another programmer’s legacy code, wondering what on earth they were thinking.

寻找您喜欢的新爱好或行业。 否则，您很快就会发现疯狂的真正定义：调试另一个程序员的遗留代码，想知道他们到底在想什么。

Alternatively, you could simply change your mindset and stop hating bugs.

或者，您可以简单地改变思维方式并停止讨厌的错误。

这是我喜欢调试的一些原因... (Here are some of the reasons why I enjoy debugging…)

1. It’s a challenge. To me, a bug is a puzzle to solve. I love puzzles, so it’s like the app is giving me an hour to play Sudoku.

   这是一个挑战 。 对我来说，错误是一个难题。 我喜欢拼图，所以好像该应用程序给了我一个小时玩Sudoku。

2. It makes me a better programmer. Debugging code is undeniably one of the best methods of learning.

   它使我成为一个更好的程序员 。 无疑，调试代码是最好的学习方法之一。

3. Sometimes it makes me laugh. To be a programmer, you need to have a good sense of humor. You also need to be able to laugh your own stupidity, or the humor of the situation.

   有时它使我发笑 。 要成为一名程序员，您需要具有良好的幽默感。 您还需要能够嘲笑自己的愚蠢或情况的幽默。

4. It is the best insight I can get into my users’ thoughts. Beyond your initial tests, you should never test your own applications — nor should another programmer. This is because you will never break your app the way your users will. The best tester I ever had was my boss’s 5-year-old son, who tested all of our iPad apps. If he couldn’t use the app, our users wouldn’t be able to either. The question when debugging doesn’t end at “How did the user do it?” but also expands to “Why did the user do it?”

   这是我可以深入了解用户思想的最佳见解 。 除了最初的测试之外， 您永远不要测试自己的应用程序-也不应该再测试另一个程序员。 这是因为您将永远不会像用户那样破坏应用程序。 我曾经遇到过的最好的测试器是我老板的5岁儿子，他测试了我们所有的iPad应用程序。 如果他无法使用该应用程序，那么我们的用户也将无法使用。 调试时的问题不止于“用户是如何做到的？” 而且还会扩展为“用户为什么这样做？”

I found this pie chart on the ProgrammerHumor subreddit that perfectly sums up my average day:

我在ProgrammerHumor subreddit上找到了这个饼图，它完美地总结了我的平均一天：

Note that the majority of time is spent implementing safeguards. This is the definition of preventative programming.

请注意，大部分时间都花在了实施保障措施上。 这就是预防性编程的定义。

If your graph is the same, great. Maybe we can exchange tips. But if you’re probably like most of us, and spend the majority of you time wondering what the hell your user did to make a fixed variable undefined or turn a string into an integer.

如果您的图形相同，那就太好了。 也许我们可以交换技巧。 但是，如果您可能像我们大多数人一样，并花大量时间在想知道您的用户做了什么，使固定变量未定义或将字符串转换为整数。

Then this post may be particularly helpful to you.

然后，该帖子可能对您特别有帮助。

为什么夏洛克·福尔摩斯(Sherlock Holmes)会成为优秀的程序员 (Why Sherlock Holmes would have been an excellent programmer)

The first Sherlock Holmes book was written way back in 1887, long before computers were invented. All of these books are packed full of lessons that you can apply to programming.

第一本《福尔摩斯》(Sherlock Holmes)书是在1887年发明的，当时计算机发明还很早。 所有这些书都挤满了可以应用于编程的课程。

If this comes as a surprise to you, remember that data has existed as long as the written word has, and that the reason computers where invented was to handle data.

如果让您感到惊讶，请记住，只要文字就存在数据，并且发明计算机的原因是要处理数据。

Sherlock Holmes is most famous for using his “method of deduction”:

福尔摩斯(Sherlock Holmes)因使用“演绎法”而闻名：

When you have eliminated the impossible, whatever remains, however improbable, must be the truth. — Sherlock Holmes in The Sign of Four

当您消除了不可能的事情之后，无论多么不可能的事情，剩下的都是事实。 — 四个星座的福尔摩斯

If I had to apply this thinking to a function it would be something like…

如果我必须将此思想应用于某个功能，它将类似于……

When you have prevented everything a function shouldn’t do, it can only do what it should.

当您阻止了某个函数不应该做的所有事情时，它只能做应该做的事情。

Let’s dive into some simple habits that can help you save countless hours of debugging by applying this theory.

让我们潜入一些简单的习惯，这些习惯可以通过应用这种理论来帮助您节省大量的调试时间。