The website information leakage attacks - ultra vires action, directory traversal, source code exposed

Server in addition to those of the famous and infamous attack vulnerabilities mentioned above, in fact, there are many other loopholes, often easily overlooked, in this section also describes several slightly.

Unauthorized Vulnerability

If you have a login system is controlled, it would be extra careful, because most likely your system is ultra vires action vulnerabilities, unauthorized operation vulnerabilities can be simply summarized as "A user can see the user's privacy or operator B Content" If your access control system there is even more need to be careful. Therefore each request needs to make a judgment of userid

The following are some loopholes in the back-end schematic Code:

// ctx is the context of the request context 
the let msgId = ctx.params.msgId; 

mysql.query ( 'the FROM msg_table the WHERE msg_id the SELECT * =?', [MsgId] );

The above code is that anyone can query any user's message, as long as you can msg_id, which is typical ultra vires loopholes, such as the need to improve it:

// ctx is the context of the request context 
the let msgId = ctx.params.msgId; 
the let userId = ctx.session.userId; // userId removed from the current login session 

mysql.query ( 'the SELECT * = the AND msg_id the FROM msg_table the WHERE? ? user_id = ', [msgId, the userId] );

Ah, probably mean, if there are more stringent access control, and that those who are involved in the operation of the database needs to be strictly verified each request, and in the design of the database table when the need to consider into account the associated userId and rights association.

Directory traversal vulnerability

Directory traversal vulnerability refers to the URL or the construction parameters ../, ./ and similar cross-ASCII encoding parent directory string, unicode coding, complete directory jump, read sensitive files in each directory operating system, also known as "arbitrary file read vulnerability. "

Directory Traversal Vulnerability principle: the program does not sufficiently sanitize user input ../ like directory skip signs, can cause the user to traverse arbitrary files on the server directory by submitting a jump. The use of multiple .. symbols, continue to jump up and eventually stay in the root /, to read arbitrary files via an absolute path.

Directory traversal vulnerability and test a few examples, general construction URL and then use the browser to directly access or use the Web vulnerability scanning tools to detect, of course, can self-written test procedures.

http://somehost.com/../../../../../../../../../etc/passwd 
http://somehost.com/some/path? = .. File / .. / Windows / of the SYSTEM.INI 

# With 00% empty character truncation is a more classic methods of attack 
http://somehost.com/some/path?file=../../Windows/system % 00.js .ini 

# using the IIS scripts directory and execute the command to move the directory 
http://somehost.com/scripts/..%5c../Windows/System32/cmd.exe?/c+dir+c : \

The method is the need for defense or URL parameters ../, ./ escaped characters such as filtration.

Physical Path Disclosure

Physical path disclosure is a low risk level defects, its harm is generally described as "An attacker could exploit this vulnerability to obtain information, to further attacks on the system," often the system error error message 500 is returned directly to the page visible due vulnerability. Sometimes you can get the physical path to the attacker bring some useful information, such as: an overview of the system file directory structure; it can be seen third-party software used by the system; perhaps get a valid username (because many people put their user name as the site's directory name).

This is to prevent leakage of good error handling back-end program, a special custom 500 error page.

Source vulnerabilities exposed

And the physical path disclosure similar to that request by an attacker can get the source code directly to the back end of your site, then you can study further attacks on the system. So what causes the exposed source code is it? Basically what happens on the server configuration, the file server can be set path which can be accessed directly, for example where a service from koa, normal koa specified directory server can go to static resources by koa-static middleware , so that static resources can be accessed through the routing path. For instance, your system source code directory like this:

|- project
    |- src
    |- static
    |- ...
|- server.js

You want to static folder paired static resource directory, you should be in server.js to make the following configuration:

const Koa = require('koa');
const serve = require('koa-static');
const app = new Koa();

app.use(serve(__dirname + '/project/static'));

However, if the static resource directory with the wrong, probably a major event, such as:

1 2	// ... app.use(serve(__dirname + '/project'));

So that all of the source code can be accessed through the route to all the servers provide static resource mechanism, so when configuring a static resource directories and paths through the server, must pay attention to testing, or is likely to create loopholes.

Finally, we hope Web developers can manage their own privacy code, note the code security issues, such products do not contain sensitive information code into external third-party site or exposed to external users, especially the front-end code is similar, private Do something confidentiality output directly in code or page. Perhaps there are many noteworthy that point, but in the final analysis Flanagan string stretched to live safe, treat each line of code should be a lot of scrutiny.