目前大多數(shù)應(yīng)用程序都會包含：服務(wù)器端邏輯、客戶端邏輯、數(shù)據(jù)存儲、數(shù)據(jù)傳輸、以及API等多個組件。與此同時(shí)，每種語言、框架、以及環(huán)境的使用，都會讓應(yīng)用程序暴露于一組獨(dú)特的漏洞之中。為了保證這些組件的安全，第一時(shí)間發(fā)現(xiàn)應(yīng)用的漏洞，進(jìn)而構(gòu)建出一個安全態(tài)勢較高的應(yīng)用，往往需要我們付出不懈的努力。

站在用戶的角度思考問題，與客戶深入溝通，找到宣漢網(wǎng)站設(shè)計(jì)與宣漢網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、主機(jī)域名、網(wǎng)頁空間、企業(yè)郵箱。業(yè)務(wù)覆蓋宣漢地區(qū)。

值得慶幸的是，大多應(yīng)用程序的漏洞都有著相似、甚至相同的底層原因。研究這些常見的漏洞類型、以及背后的原因，將有助于我們對應(yīng)用程序進(jìn)行恰當(dāng)?shù)姆雷o(hù)。

下面，我將和您一起討論影響Angular和React應(yīng)用的如下六種最常見的漏洞，以及如何發(fā)現(xiàn)和預(yù)防它們：

• 身份驗(yàn)證繞過
• 訪問控制不當(dāng)
• 開放式重定向
• 跨站請求偽造 (CSRF)
• 模板注入
• 跨站點(diǎn)腳本包含 (XSSI)

身份驗(yàn)證繞過

身份驗(yàn)證是指在執(zhí)行敏感操作、或訪問敏感數(shù)據(jù)之前，先驗(yàn)明身份的合法性。如果在應(yīng)用程序上未能正確地實(shí)施身份驗(yàn)證，那么攻擊者將可以利用此類錯誤配置，來訪問他們本不該能夠訪問到的服務(wù)與功能。例如，Angular通常使用AppRoutingModule來進(jìn)行路由。在將用戶引導(dǎo)至應(yīng)用程序中的敏感路由之前，您應(yīng)該檢查用戶是否已通過了身份驗(yàn)證，并被授權(quán)了訪問該資源。請參考如下代碼段：

@NgModule({
    imports: [RouterModule.forRoot([
    
        // These paths are available to all users.
        { path: '', component: HomeComponent },
        { path: 'features', component: FeaturesComponent },
        { path: 'login', component: LoginComponent },
    
        // These routes are only available to users after logging in.
        { path: 'feed', component: FeedComponent, canActivate: [ AuthGuard ]},
        { path: 'profile', component: ProfileComponent, canActivate: [ AuthGuard ]},
    
        // This is the fall-through component when the route is not recognized.
        { path: '**', component: PageNotFoundComponent}
    
 ])],
        
    exports: [RouterModule]
        
 })
    
 export class AppRoutingModule {}

訪問控制不當(dāng)

攻擊者會想方設(shè)法繞過那些訪問權(quán)限控制實(shí)施不當(dāng)?shù)膽?yīng)用程序。訪問控制不僅僅只包括身份驗(yàn)證。也就是說，我們除了需要證明用戶的身份(即“你是誰?”)，還要通過應(yīng)用程序授予相應(yīng)的權(quán)限(即“你可以做什么?”)。只有通過兩者雙管齊下，才能共同確保用戶不會訪問到超出其權(quán)限的服務(wù)與功能。

目前，我們有多種方式為用戶配置授權(quán)，其中包括：基于角色的訪問控制、基于所有權(quán)的訪問控制、以及訪問控制列表等。而開發(fā)人員常犯的一種錯誤是在客戶端執(zhí)行授權(quán)檢查。由于攻擊者可以操控和覆蓋客戶端的檢查，因此這是不安全的?？梢姡祟愂跈?quán)檢查必須使用服務(wù)器端的代碼來執(zhí)行。請參考如下代碼段：

export class AdministratorGuard implements CanActivate {
  constructor(private authService: AuthService, private router: Router) {}
  canActivate(next: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable {
    // Check whether this user is an administratoor.  
    return this.authService.isAdmin().pipe(
      map(isAdmin => {
        if (!isAdmin) {
          return this.router.parseUrl('/')
        }
        return isAdmin
      })
    )
  }
}
export class AuthService {
  constructor(private http: HttpClient) {}
  // Whether the user is currently logged in.
  loggedIn: boolean | null = null
  // The user object object encompassing the user's name and role. Will be set
  user: User | null = null
  // Check whether the current user is an administrator.
  isAdmin(): Observable {
    return this.getCurrentUser().pipe(map(user => {
      return user != null && user.role === 'admin'
    }))
  }
  // Get the user definition from local state, or the server (if this is the first time we are checking).
  getCurrentUser(): Observable {
    if (this.loggedIn !== null) {
      return of(this.user)
    }
    return this.http.get('/api/auth', {
      responseType: 'json'
    }).pipe(
      tap({
        next: user => {
          // If we get a user definition from the server it indicates this user is logged in.  
          this.user     = user
          this.loggedIn = true
        },
        error: error => {
          // A 401 response from the server indicates this user is not logged in.  
          this.user     = null
          this.loggedIn = false
        }
      }),
      catchError(() => {
        return of(null)
      })
    )
  }
}
export interface User {
    username: string
    role:     string
}

開放式重定向

例如，當(dāng)未經(jīng)身份驗(yàn)證的用戶嘗試著訪問需要登錄后才能看到的頁面時(shí)，網(wǎng)站就需要將該用戶自動重定向到登錄頁面，并在他們通過了身份驗(yàn)證之后，再讓其返回到原來的位置。

在開放式重定向攻擊發(fā)生時(shí)，攻擊者通過向用戶提供來自合法站點(diǎn)的URL，以欺騙用戶訪問某個外部站點(diǎn)。也就是說，該URL會將其重定到其他站點(diǎn)。而該站點(diǎn)一面設(shè)法讓用戶相信他們?nèi)匀辉谠季W(wǎng)站上，一面幫助攻擊者構(gòu)建出更加看似可信的網(wǎng)絡(luò)釣魚活動。

為了防止開放式重定向，您需要確保應(yīng)用程序不會輕易將用戶重定向到那些惡意站點(diǎn)的位置。例如，您可以通過驗(yàn)證重定向URL，來完全禁止離站重定向行為。請參考如下代碼段：

export class LoginComponent {
    
  // The username and password entered by the user in the login form.
  username = '';
  password = '';
    
  // The destination URL to redirect the user to once they log in successfully.
  destinationURL = '/feed'
    
  constructor(private authService : AuthService,
              private route       : ActivatedRoute,
              private router      : Router) { }
    
  ngOnInit() {
    this.destinationURL = this.route.snapshot.queryParams['destination'] || '/feed';
  }
    
  onSubmit() {
    this.authService.login(this.username, this.password)
      .subscribe(
        () => {
          // After the user has lgged in, redirect them to their desired destination.
          let url = this.destinationURL
    
          // Confirm that the URL is a relative path - i.e. starting with a single '/' characters.
          if (!url.match(/^\/[^\/\\]/)) {
            url = '/feed'
          }
    
          this.router.navigate([ url ])
        })
  }
}

當(dāng)然，我們還有許多其他方法可以防止開放式重定向的發(fā)生。例如：對請求引用方予以檢查、或使用頁面索引進(jìn)行重定向。不過，正因?yàn)轵?yàn)證URL相對比較困難，因此開放式重定向仍然是當(dāng)代Web應(yīng)用普遍存在的問題。

跨站請求偽造

跨站點(diǎn)請求偽造(Cross-Site Request Forgery，CSRF)是一種客戶端技術(shù)，可用于攻擊Web應(yīng)用的其他用戶。使用CSRF，攻擊者可以發(fā)送虛假的、來自受害者的HTTP請求，去執(zhí)行攻擊者的危害性操作。例如，攻擊者會在未經(jīng)許可的情況下，更改受害者的密碼、或從其銀行賬戶里轉(zhuǎn)賬。

與開放式重定向不同，我們目前已有一種行之有效的對抗CSRF的方法，即：使用CSRF令牌和SameSite Cookie的組合，以避免使用GET請求進(jìn)行各項(xiàng)狀態(tài)更改的操作。例如，Angular允許您使用HttpClientXsrfModule模塊，向HTTP請求添加防偽的令牌。請參考如下代碼段：

@NgModule({
  declarations: [],
  imports: [
    BrowserModule,
    HttpClientModule,
    HttpClientXsrfModule.withOptions({
      cookieName: 'XSRF-TOKEN',
      headerName: 'X-CSRF-TOKEN'
    }),
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule {
}

模板注入

類似于HTML文件的Web模板，為開發(fā)人員提供了一種通過將應(yīng)用數(shù)據(jù)與靜態(tài)模板相結(jié)合，以指定如何呈現(xiàn)頁面的方法。此功能允許開發(fā)人員將從數(shù)據(jù)庫或HTTP請求中檢索到的動態(tài)內(nèi)容，插入到網(wǎng)頁中。

顧名思義，模板注入需要注入到網(wǎng)頁的模板中。根據(jù)受感染應(yīng)用的權(quán)限，攻擊者可以通過使用模板注入的漏洞，來讀取敏感文件、執(zhí)行惡意代碼、或提升他們在系統(tǒng)上的各種權(quán)限。下面展示了Angular模板的不安全用法。它允許攻擊者通過URL的哈希值，來惡意注入代碼：

@Component({
  selector: 'app-header',
  template: '
' + (window.location.hash || 'Home') + '
'
})
export class HeaderComponent {}

注意：請千萬不要直接將用戶提供的輸入連接到模板中，而應(yīng)該使用模板引擎的內(nèi)置替換機(jī)制，來安全地嵌入動態(tài)輸入。請參考如下代碼段：

@Component({
  selector: 'app-header',
  template: '
{{ title }}
'
})
export class HeaderComponent {
  title = ''  
        
  ngOnInit() {
    this.title = window.location.hash || 'Home';
  }
}

跨站點(diǎn)腳本

跨站點(diǎn)腳本包含的攻擊也稱為XSSI(Cross-Site Script Inclusion)。此類攻擊發(fā)生在當(dāng)惡意站點(diǎn)包含了來自受害者站點(diǎn)的Javascript，并通過腳本提取其敏感信息時(shí)。

同源策略（same-origin policy，SOP）通常可以起到控制數(shù)據(jù)跨源（cross-origins）訪問的作用。不過，SOP并不能限制JavaScript代碼，而且HTML