我应该了解哪些常见的网络漏洞？

时间：2022-09-11 10:36:24

I'm pretty green still when it comes to web programming, I've spent most of my time on client applications. So I'm curious about the common exploits I should fear/test for in my site.

在网络编程方面,我还很绿,我把大部分时间花在客户端应用程序上。所以我很好奇我应该在我的网站上担心/测试的常见漏洞。

13 个解决方案

#1

29  

OWASP keeps a list of the Top 10 web attacks to watch our for, in addition to a ton of other useful security information for web development.

除了用于Web开发的大量其他有用的安全信息之外,OWASP还会列出十大网络攻击列表以供我们观看。

#2

33  

I'm posting the OWASP Top 2007 abbreviated list here so people don't have to look through to another link and in case the source goes down.

我在这里发布了OWASP Top 2007缩写列表,这样人们就不必查看另一个链接,以防万一。

Cross Site Scripting (XSS)

  • XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

    • 每当应用程序获取用户提供的数据并将其发送到Web浏览器而不首先验证或编码该内容时,就会出现XSS漏洞。 XSS允许攻击者在受害者的浏览器中执行脚本,这可能会劫持用户会话,破坏网站,可能会引入蠕虫等。

Injection Flaws

  • Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

    • 注入漏洞,特别是SQL注入,在Web应用程序中很常见。当用户提供的数据作为命令或查询的一部分发送到解释器时,会发生注入。攻击者的恶意数据欺骗解释器执行非预期的命令或更改数据。

Malicious File Execution

  • Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

    • 易受远程文件包含(RFI)攻击的代码允许攻击者包含恶意代码和数据,从而导致破坏性攻击,例如整个服务器受损。恶意文件执行攻击会影响PHP,XML和任何接受用户文件名或文件的框架。

Insecure Direct Object Reference

  • A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

    • 当开发人员将对内部实现对象(如文件,目录,数据库记录或键)的引用作为URL或表单参数公开时,就会发生直接对象引用。攻击者可以在未经授权的情况下操纵这些引用来访问其他对象。

Cross Site Request Forgery (CSRF)

  • A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

    • CSRF攻击强制登录受害者的浏览器向易受攻击的Web应用程序发送预先验证的请求,然后强制受害者的浏览器执行恶意操作以使攻击者受益。 CSRF可以像它攻击的Web应用程序一样强大。

Information Leakage and Improper Error Handling

  • Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.

    • 应用程序可能会无意中泄露有关其配置,内部工作或通过各种应用程序问题侵犯隐私的信息。攻击者利用此弱点窃取敏感数据,或进行更严重的攻击。

Broken Authentication and Session Management

  • Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.

    • 帐户凭据和会话令牌通常未得到适当保护。攻击者会破坏密码,密钥或身份验证令牌以承担其他用户的身份。

Insecure Cryptographic Storage

  • Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

    • Web应用程序很少正确使用加密功能来保护数据和凭据。攻击者使用受弱保护的数据进行身份盗窃和其他犯罪,如信用卡欺诈。

Insecure Communications

  • Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

    • 当需要保护敏感通信时,应用程序经常无法加密网络流量。

Failure to Restrict URL Access

  • Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

    • 通常,应用程序仅通过阻止向未授权用户显示链接或URL来保护敏感功能。攻击者可以通过直接访问这些URL来利用此漏洞访问和执行未经授权的操作。

The Open Web Application Security Project

开放式Web应用程序安全项目

-Adam

#3

28  

These three are the most important:

这三个是最重要的:

#4

10  

Everyone's going to say "SQL Injection", because it's the scariest-sounding vulnerability and the easiest one to get your head around. Cross-Site Scripting (XSS) is going to come in second place, because it's also easy to understand. "Poor input validation" isn't a vulnerability, but rather an evaluation of a security best practice.

每个人都会说“SQL注入”,因为它是最可怕的漏洞,也是最容易理解的漏洞。跨站点脚本(XSS)将排在第二位,因为它也很容易理解。 “输入验证不良”不是漏洞,而是对安全最佳实践的评估。

Let's try this from a different perspective. Here are features that, when implemented in a web application, are likely to mess you up:

让我们从不同的角度来试试这个。以下功能在Web应用程序中实现时可能会让您感到困惑:

  • Dynamic SQL (for instance, UI query builders). By now, you probably know that the only reliably safe way to use SQL in a web app is to use parameterized queries, where you explicitly bind each parameter in the query to a variable. The places where I see web apps most frequently break this rule is when the malicious input isn't an obvious parameter (like a name), but rather a query attribute. An obvious example are the iTunes-like "Smart Playlist" query builders you see on search sites, where things like where-clause operators are passed directly to the backend. Another great rock to turn over are table column sorts, where you'll see things like DESC exposed in HTTP parameters.

    动态SQL(例如,UI查询构建器)。到目前为止,您可能知道在Web应用程序中使用SQL的唯一可靠安全方法是使用参数化查询,您可以将查询中的每个参数显式绑定到变量。我看到Web应用程序最常破坏此规则的地方是恶意输入不是明显的参数(如名称),而是查询属性。一个明显的例子是您在搜索网站上看到的类似iTunes的“智能播放列表”查询构建器,其中where子句运算符等内容直接传递给后端。翻转的另一个好方法是表列排序,在这里您可以看到在HTTP参数中暴露的DESC之类的东西。

  • File upload. File upload messes people up because file pathnames look suspiciously like URL pathnames, and because web servers make it easy to implement the "download" part just by aiming URLs at directories on the filesystem. 7 out of 10 upload handlers we test allow attackers to access arbitrary files on the server, because the app developers assumed the same permissions were applied to the filesystem "open()" call as are applied to queries.

    上传文件。文件上传会让人感到困惑,因为文件路径名看起来像URL路径名,并且因为Web服务器只需将URL瞄准文件系统上的目录就可以轻松实现“下载”部分。我们测试的10个上传处理程序中有7个允许攻击者访问服务器上的任意文件,因为应用程序开发人员假定相同的权限应用于文件系统“open()”调用,如同应用于查询一样。

  • Password storage. If your application can mail me back my raw password when I lose it, you fail. There's a single safe reliable answer for password storage, which is bcrypt; if you're using PHP, you probably want PHPpass.

    密码存储。如果您的应用程序在丢失时可以将我的原始密码邮寄给我,那么您将失败。密码存储有一个安全可靠的答案,就是bcrypt;如果你使用PHP,你可能想要PHPpass。

  • Random number generation. A classic attack on web apps: reset another user's password, and, because the app is using the system's "rand()" function, which is not crypto-strong, the password is predictable. This also applies anywhere you're doing cryptography. Which, by the way, you shouldn't be doing: if you're relying on crypto anywhere, you're very likely vulnerable.

    随机数生成。对网络应用程序的经典攻击:重置另一个用户的密码,并且,因为该应用程序正在使用系统的“rand()”函数,该函数不具有加密性,因此密码是可预测的。这也适用于您正在进行加密的任何地方。顺便说一句,你不应该这样做:如果你在任何地方都依赖加密,你很可能很脆弱。

  • Dynamic output. People put too much faith in input validation. Your chances of scrubbing user inputs of all possible metacharacters, especially in the real world, where metacharacters are necessary parts of user input, are low. A much better approach is to have a consistent regime of filtering database outputs and transforming them into HTML entities, like quot, gt, and lt. Rails will do this for you automatically.

    动态输出。人们对输入验证过于信任。您擦除所有可能元字符的用户输入的机会很少,特别是在现实世界中,元字符是用户输入的必要部分。更好的方法是使用一致的过滤数据库输出的方法,并将它们转换为HTML实体,如quot,gt和lt。 Rails会自动为您完成此操作。

  • Email. Plenty of applications implement some sort of outbound mail capability that enable an attacker to either create an anonymous account, or use no account at all, to send attacker-controlled email to arbitrary email addresses.

    电子邮件。许多应用程序实现某种出站邮件功能,使攻击者能够创建匿名帐户,或者根本不使用任何帐户,将攻击者控制的电子邮件发送到任意电子邮件地址。

Beyond these features, the #1 mistake you are likely to make in your application is to expose a database row ID somewhere, so that user X can see data for user Y simply by changing a number from "5" to "6".

除了这些功能之外,您可能在应用程序中犯的第一个错误是在某处公开数据库行ID,这样用户X只需将数字从“5”更改为“6”即可查看用户Y的数据。

#5

10  

bool UserCredentialsOK(User user)
{

    if (user.Name == "modesty")
        return false;
    else
        // perform other checks
}

#6

3  

SQL INJECTION ATTACKS. They are easy to avoid but all too common.

SQL注入攻击。它们很容易避免但很常见。

NEVER EVER EVER EVER (did I mention "ever"?) trust user information passed to you from form elements. If your data is not vetted before being passed into other logical layers of your application, you might as well give the keys to your site to a stranger on the street.

永远不会永远(我是否曾提到“永远”?)信任从表单元素传递给您的用户信息。如果您的数据在传递到应用程序的其他逻辑层之前未经过审查,您也可以将网站的密钥提供给街道上的陌生人。

You do not mention what platform you are on but if on ASP.NET get a start with good ol' Scott Guthrie and his article "Tip/Trick: Guard Against SQL Injection Attacks".

你没有提到你所使用的平台,但是如果在ASP.NET上开始使用好的'Scott Guthrie和他的文章“Tip / Trick:Guard Against SQL Injection Attacks”。

After that you need to consider what type of data you will permit users to submit into and eventually out of your database. If you permit HTML to be inserted and then later presented you are wide-open for Cross Site Scripting attacks (known as XSS).

之后,您需要考虑允许用户提交并最终退出数据库的数据类型。如果您允许插入HTML,然后再显示您对跨站点脚本攻击(称为XSS)的开放性。

Those are the two that come to mind for me, but our very own Jeff Atwood had a good article at Coding Horror with a review of the book "19 Deadly Sins of Software Security".

这些是我想到的两个,但是我们自己的Jeff Atwood在Coding Horror上发表了一篇很好的文章,回顾了“软件安全的19个致命罪”。

#7

3  

Most people here have mentioned SQL Injection and XSS, which is kind of correct, but don't be fooled - the most important things you need to worry about as a web developer is INPUT VALIDATION, which is where XSS and SQL Injection stem from.

这里的大多数人都提到了SQL注入和XSS,这是正确的,但不要被愚弄 - 作为Web开发人员,您需要担心的最重要的事情是INPUT VALIDATION,这是XSS和SQL注入源自的地方。

For instance, if you have a form field that will only ever accept integers, make sure you're implementing something at both the client-side AND the server-side to sanitise the data.

例如,如果您有一个只接受整数的表单字段,请确保您在客户端和服务器端实现某些操作来清理数据。

Check and double check any input data especially if it's going to end up in an SQL query. I suggest building an escaper function and wrap it around anything going into a query. For instance:

检查并仔细检查任何输入数据,特别是如果它最终会在SQL查询中结束。我建议构建一个escaper函数并将其包装到查询中。例如:

$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";

Likewise, if you're going to display any user-inputted information onto a webpage, make sure you've stripped any <script> tags or anything else that might result in Javascript execution (such as onLoad= onMouseOver= etc. attributes on tags).

同样,如果您要在网页上显示任何用户输入的信息,请确保您已剥离任何

#8

1  

This is also a short little presentation on security by one of wordpress's core developers.

这也是wordpress的核心开发人员之一关于安全性的简短介绍。

Security in wordpress

wordpress的安全性

it covers all of the basic security problems in web apps.

它涵盖了Web应用程序中的所有基本安全问题。

#9

0  

The most common are probably database injection attacks and cross-site scripting attacks; mainly because those are the easiest to accomplish (that's likely because those are the ones programmers are laziest about).

最常见的可能是数据库注入攻击和跨站点脚本攻击;主要是因为那些是最容易实现的(这可能是因为那些是程序员最懒的)。

#10

0  

You can see even on this site that the most damaging things you'll be looking after involve code injection into your application, so XSS (Cross Site Scripting) and SQL injection (@Patrick's suggestions) are your biggest concerns. Basically you're going to want to make sure that if your application allows for a user to inject any code whatsoever, it's regulated and tested to be sure that only things you're sure you want to allow (an html link, image, etc) are passed, and nothing else is executed.

您甚至可以在此站点上看到,您将要关注的最具破坏性的事情是将代码注入到您的应用程序中,因此XSS(跨站点脚本)和SQL注入(@ Patrick的建议)是您最关心的问题。基本上你会想要确保如果你的应用程序允许用户注入任何代码,它会受到监管和测试,以确保只有你确定要允许的东西(HTML链接,图像等) )被传递,没有别的执行。

#11

0  

SQL Injection. Cross Site Scripting.

SQL注入。跨站脚本。

#12

0  

Using stored procedures and/or parameterized queries will go a long way in protecting you from sql injection. Also do NOT have your web app access the database as sa or dbo - set a up a standard user account and set the permissions.

使用存储过程和/或参数化查询将大大有助于保护您免受sql注入。另外,不要让您的Web应用程序以sa或dbo的身份访问数据库 - 设置标准用户帐户并设置权限。

AS for XSS (cross site scripting) ASP.NET has some built in protections. The best thing is to filter input using validation controls and Regex.

AS for XSS(跨站点脚本)ASP.NET有一些内置的保护。最好的方法是使用验证控件和Regex过滤输入。

#13

0  

I'm no expert, but from what I learned so far the golden rule is not to trust any user data (GET, POST, COOKIE). Common attack types and how to save yourself:

我不是专家,但从我到目前为止所学到的,黄金法则不是信任任何用户数据(GET,POST,COOKIE)。常见的攻击类型以及如何自救:

  1. SQL Injection Attack: Use prepared queries

    2. SQL注入攻击:使用准备好的查询

  2. Cross Site Scripting: Send no user data to browser without filtering/escaping first. This also includes user data stored in database, which originally came from users.

    3. 跨站点脚本:不向用户发送任何用户数据,而不先过滤/转义。这还包括存储在数据库中的用户数据,该数据最初来自用户。

#1

29  

OWASP keeps a list of the Top 10 web attacks to watch our for, in addition to a ton of other useful security information for web development.

除了用于Web开发的大量其他有用的安全信息之外,OWASP还会列出十大网络攻击列表以供我们观看。

#2

33  

I'm posting the OWASP Top 2007 abbreviated list here so people don't have to look through to another link and in case the source goes down.

我在这里发布了OWASP Top 2007缩写列表,这样人们就不必查看另一个链接,以防万一。

Cross Site Scripting (XSS)

  • XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc.

    • 每当应用程序获取用户提供的数据并将其发送到Web浏览器而不首先验证或编码该内容时,就会出现XSS漏洞。 XSS允许攻击者在受害者的浏览器中执行脚本,这可能会劫持用户会话,破坏网站,可能会引入蠕虫等。

Injection Flaws

  • Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

    • 注入漏洞,特别是SQL注入,在Web应用程序中很常见。当用户提供的数据作为命令或查询的一部分发送到解释器时,会发生注入。攻击者的恶意数据欺骗解释器执行非预期的命令或更改数据。

Malicious File Execution

  • Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

    • 易受远程文件包含(RFI)攻击的代码允许攻击者包含恶意代码和数据,从而导致破坏性攻击,例如整个服务器受损。恶意文件执行攻击会影响PHP,XML和任何接受用户文件名或文件的框架。

Insecure Direct Object Reference

  • A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

    • 当开发人员将对内部实现对象(如文件,目录,数据库记录或键)的引用作为URL或表单参数公开时,就会发生直接对象引用。攻击者可以在未经授权的情况下操纵这些引用来访问其他对象。

Cross Site Request Forgery (CSRF)

  • A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

    • CSRF攻击强制登录受害者的浏览器向易受攻击的Web应用程序发送预先验证的请求,然后强制受害者的浏览器执行恶意操作以使攻击者受益。 CSRF可以像它攻击的Web应用程序一样强大。

Information Leakage and Improper Error Handling

  • Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.

    • 应用程序可能会无意中泄露有关其配置,内部工作或通过各种应用程序问题侵犯隐私的信息。攻击者利用此弱点窃取敏感数据,或进行更严重的攻击。

Broken Authentication and Session Management

  • Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.

    • 帐户凭据和会话令牌通常未得到适当保护。攻击者会破坏密码,密钥或身份验证令牌以承担其他用户的身份。

Insecure Cryptographic Storage

  • Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

    • Web应用程序很少正确使用加密功能来保护数据和凭据。攻击者使用受弱保护的数据进行身份盗窃和其他犯罪,如信用卡欺诈。

Insecure Communications

  • Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

    • 当需要保护敏感通信时,应用程序经常无法加密网络流量。

Failure to Restrict URL Access

  • Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

    • 通常,应用程序仅通过阻止向未授权用户显示链接或URL来保护敏感功能。攻击者可以通过直接访问这些URL来利用此漏洞访问和执行未经授权的操作。

The Open Web Application Security Project

开放式Web应用程序安全项目

-Adam

#3

28  

These three are the most important:

这三个是最重要的:

#4

10  

Everyone's going to say "SQL Injection", because it's the scariest-sounding vulnerability and the easiest one to get your head around. Cross-Site Scripting (XSS) is going to come in second place, because it's also easy to understand. "Poor input validation" isn't a vulnerability, but rather an evaluation of a security best practice.

每个人都会说“SQL注入”,因为它是最可怕的漏洞,也是最容易理解的漏洞。跨站点脚本(XSS)将排在第二位,因为它也很容易理解。 “输入验证不良”不是漏洞,而是对安全最佳实践的评估。

Let's try this from a different perspective. Here are features that, when implemented in a web application, are likely to mess you up:

让我们从不同的角度来试试这个。以下功能在Web应用程序中实现时可能会让您感到困惑:

  • Dynamic SQL (for instance, UI query builders). By now, you probably know that the only reliably safe way to use SQL in a web app is to use parameterized queries, where you explicitly bind each parameter in the query to a variable. The places where I see web apps most frequently break this rule is when the malicious input isn't an obvious parameter (like a name), but rather a query attribute. An obvious example are the iTunes-like "Smart Playlist" query builders you see on search sites, where things like where-clause operators are passed directly to the backend. Another great rock to turn over are table column sorts, where you'll see things like DESC exposed in HTTP parameters.

    动态SQL(例如,UI查询构建器)。到目前为止,您可能知道在Web应用程序中使用SQL的唯一可靠安全方法是使用参数化查询,您可以将查询中的每个参数显式绑定到变量。我看到Web应用程序最常破坏此规则的地方是恶意输入不是明显的参数(如名称),而是查询属性。一个明显的例子是您在搜索网站上看到的类似iTunes的“智能播放列表”查询构建器,其中where子句运算符等内容直接传递给后端。翻转的另一个好方法是表列排序,在这里您可以看到在HTTP参数中暴露的DESC之类的东西。

  • File upload. File upload messes people up because file pathnames look suspiciously like URL pathnames, and because web servers make it easy to implement the "download" part just by aiming URLs at directories on the filesystem. 7 out of 10 upload handlers we test allow attackers to access arbitrary files on the server, because the app developers assumed the same permissions were applied to the filesystem "open()" call as are applied to queries.

    上传文件。文件上传会让人感到困惑,因为文件路径名看起来像URL路径名,并且因为Web服务器只需将URL瞄准文件系统上的目录就可以轻松实现“下载”部分。我们测试的10个上传处理程序中有7个允许攻击者访问服务器上的任意文件,因为应用程序开发人员假定相同的权限应用于文件系统“open()”调用,如同应用于查询一样。

  • Password storage. If your application can mail me back my raw password when I lose it, you fail. There's a single safe reliable answer for password storage, which is bcrypt; if you're using PHP, you probably want PHPpass.

    密码存储。如果您的应用程序在丢失时可以将我的原始密码邮寄给我,那么您将失败。密码存储有一个安全可靠的答案,就是bcrypt;如果你使用PHP,你可能想要PHPpass。

  • Random number generation. A classic attack on web apps: reset another user's password, and, because the app is using the system's "rand()" function, which is not crypto-strong, the password is predictable. This also applies anywhere you're doing cryptography. Which, by the way, you shouldn't be doing: if you're relying on crypto anywhere, you're very likely vulnerable.

    随机数生成。对网络应用程序的经典攻击:重置另一个用户的密码,并且,因为该应用程序正在使用系统的“rand()”函数,该函数不具有加密性,因此密码是可预测的。这也适用于您正在进行加密的任何地方。顺便说一句,你不应该这样做:如果你在任何地方都依赖加密,你很可能很脆弱。

  • Dynamic output. People put too much faith in input validation. Your chances of scrubbing user inputs of all possible metacharacters, especially in the real world, where metacharacters are necessary parts of user input, are low. A much better approach is to have a consistent regime of filtering database outputs and transforming them into HTML entities, like quot, gt, and lt. Rails will do this for you automatically.

    动态输出。人们对输入验证过于信任。您擦除所有可能元字符的用户输入的机会很少,特别是在现实世界中,元字符是用户输入的必要部分。更好的方法是使用一致的过滤数据库输出的方法,并将它们转换为HTML实体,如quot,gt和lt。 Rails会自动为您完成此操作。

  • Email. Plenty of applications implement some sort of outbound mail capability that enable an attacker to either create an anonymous account, or use no account at all, to send attacker-controlled email to arbitrary email addresses.

    电子邮件。许多应用程序实现某种出站邮件功能,使攻击者能够创建匿名帐户,或者根本不使用任何帐户,将攻击者控制的电子邮件发送到任意电子邮件地址。

Beyond these features, the #1 mistake you are likely to make in your application is to expose a database row ID somewhere, so that user X can see data for user Y simply by changing a number from "5" to "6".

除了这些功能之外,您可能在应用程序中犯的第一个错误是在某处公开数据库行ID,这样用户X只需将数字从“5”更改为“6”即可查看用户Y的数据。

#5

10  

bool UserCredentialsOK(User user)
{

    if (user.Name == "modesty")
        return false;
    else
        // perform other checks
}

#6

3  

SQL INJECTION ATTACKS. They are easy to avoid but all too common.

SQL注入攻击。它们很容易避免但很常见。

NEVER EVER EVER EVER (did I mention "ever"?) trust user information passed to you from form elements. If your data is not vetted before being passed into other logical layers of your application, you might as well give the keys to your site to a stranger on the street.

永远不会永远(我是否曾提到“永远”?)信任从表单元素传递给您的用户信息。如果您的数据在传递到应用程序的其他逻辑层之前未经过审查,您也可以将网站的密钥提供给街道上的陌生人。

You do not mention what platform you are on but if on ASP.NET get a start with good ol' Scott Guthrie and his article "Tip/Trick: Guard Against SQL Injection Attacks".

你没有提到你所使用的平台,但是如果在ASP.NET上开始使用好的'Scott Guthrie和他的文章“Tip / Trick:Guard Against SQL Injection Attacks”。

After that you need to consider what type of data you will permit users to submit into and eventually out of your database. If you permit HTML to be inserted and then later presented you are wide-open for Cross Site Scripting attacks (known as XSS).

之后,您需要考虑允许用户提交并最终退出数据库的数据类型。如果您允许插入HTML,然后再显示您对跨站点脚本攻击(称为XSS)的开放性。

Those are the two that come to mind for me, but our very own Jeff Atwood had a good article at Coding Horror with a review of the book "19 Deadly Sins of Software Security".

这些是我想到的两个,但是我们自己的Jeff Atwood在Coding Horror上发表了一篇很好的文章,回顾了“软件安全的19个致命罪”。

#7

3  

Most people here have mentioned SQL Injection and XSS, which is kind of correct, but don't be fooled - the most important things you need to worry about as a web developer is INPUT VALIDATION, which is where XSS and SQL Injection stem from.

这里的大多数人都提到了SQL注入和XSS,这是正确的,但不要被愚弄 - 作为Web开发人员,您需要担心的最重要的事情是INPUT VALIDATION,这是XSS和SQL注入源自的地方。

For instance, if you have a form field that will only ever accept integers, make sure you're implementing something at both the client-side AND the server-side to sanitise the data.

例如,如果您有一个只接受整数的表单字段,请确保您在客户端和服务器端实现某些操作来清理数据。

Check and double check any input data especially if it's going to end up in an SQL query. I suggest building an escaper function and wrap it around anything going into a query. For instance:

检查并仔细检查任何输入数据,特别是如果它最终会在SQL查询中结束。我建议构建一个escaper函数并将其包装到查询中。例如:

$query = "SELECT field1, field2 FROM table1 WHERE field1 = '" . myescapefunc($userinput) . "'";

Likewise, if you're going to display any user-inputted information onto a webpage, make sure you've stripped any <script> tags or anything else that might result in Javascript execution (such as onLoad= onMouseOver= etc. attributes on tags).

同样,如果您要在网页上显示任何用户输入的信息,请确保您已剥离任何

#8

1  

This is also a short little presentation on security by one of wordpress's core developers.

这也是wordpress的核心开发人员之一关于安全性的简短介绍。

Security in wordpress

wordpress的安全性

it covers all of the basic security problems in web apps.

它涵盖了Web应用程序中的所有基本安全问题。

#9

0  

The most common are probably database injection attacks and cross-site scripting attacks; mainly because those are the easiest to accomplish (that's likely because those are the ones programmers are laziest about).

最常见的可能是数据库注入攻击和跨站点脚本攻击;主要是因为那些是最容易实现的(这可能是因为那些是程序员最懒的)。

#10

0  

You can see even on this site that the most damaging things you'll be looking after involve code injection into your application, so XSS (Cross Site Scripting) and SQL injection (@Patrick's suggestions) are your biggest concerns. Basically you're going to want to make sure that if your application allows for a user to inject any code whatsoever, it's regulated and tested to be sure that only things you're sure you want to allow (an html link, image, etc) are passed, and nothing else is executed.

您甚至可以在此站点上看到,您将要关注的最具破坏性的事情是将代码注入到您的应用程序中,因此XSS(跨站点脚本)和SQL注入(@ Patrick的建议)是您最关心的问题。基本上你会想要确保如果你的应用程序允许用户注入任何代码,它会受到监管和测试,以确保只有你确定要允许的东西(HTML链接,图像等) )被传递,没有别的执行。

#11

0  

SQL Injection. Cross Site Scripting.

SQL注入。跨站脚本。

#12

0  

Using stored procedures and/or parameterized queries will go a long way in protecting you from sql injection. Also do NOT have your web app access the database as sa or dbo - set a up a standard user account and set the permissions.

使用存储过程和/或参数化查询将大大有助于保护您免受sql注入。另外,不要让您的Web应用程序以sa或dbo的身份访问数据库 - 设置标准用户帐户并设置权限。

AS for XSS (cross site scripting) ASP.NET has some built in protections. The best thing is to filter input using validation controls and Regex.

AS for XSS(跨站点脚本)ASP.NET有一些内置的保护。最好的方法是使用验证控件和Regex过滤输入。

#13

0  

I'm no expert, but from what I learned so far the golden rule is not to trust any user data (GET, POST, COOKIE). Common attack types and how to save yourself:

我不是专家,但从我到目前为止所学到的,黄金法则不是信任任何用户数据(GET,POST,COOKIE)。常见的攻击类型以及如何自救:

  1. SQL Injection Attack: Use prepared queries

    2. SQL注入攻击:使用准备好的查询

  2. Cross Site Scripting: Send no user data to browser without filtering/escaping first. This also includes user data stored in database, which originally came from users.

    3. 跨站点脚本:不向用户发送任何用户数据,而不先过滤/转义。这还包括存储在数据库中的用户数据,该数据最初来自用户。

标签：

相关文章